1

LangEdge,Inc.

認証から見たリモート署名
利用認証 と 鍵認可

プログラマ/取締役
宮地直人（miyachi@langedge.jp）

２０２０年７月２９日

2LangEdge,Inc.

電子署名方式の概要
電子署名方式ローカル署名
本人型
電子署名

クライアント署名

本人性

非改ざん性

補足

PKI証明書デジタル署名全てをローカル処理

PKI証明書デジタル署名（秘密鍵はローカル管理）

署名値計算はローカル処理
その他はリモート処理（秘密鍵はローカル管理）

リモート署名立会人型電子署名

PKI証明書（認証結果）

認証結果（立会人保証）

エビデンス保管型電子署名

認証結果（認証型電子署名）（事業者保証）デジタル署名全てをリモート処理（秘密鍵はリモート管理）

デジタル署名

認証結果にて本人性を保証
立会人はPKI証明書で保証（別途）

米国のクラウド署名で多かった方式

 リモート署名と立会人型は似た方式だが、認証後のデジタル署名が本人か立会人かが異なる。立会人型では認証結果を証拠として残す必要があるが、本人の秘密鍵を管理をする必要が無いので簡易な運用が可能となる。リモート署名は検証情報が署名文書に含まれるので検証が簡易に行える。
 立会人型はエビデンス保管型に立会人のデジタル署名を追加した方式となる。最近
では米国のクラウド署名も立会人型に移行またはオプションにてリモート署名も利用可能になっている。

3

LangEdge,Inc.

リモート署名ガイドライン
JT2A（日本トラストテクノロジー協議会）より2020年4月公開。
https://www.jnsa.org/result/jt2a/2020/index.html
3つのレベルに分けて解説している。
レベル

概要

電子署名に利用する署名者の署名鍵を安全に管理レベル１ するために最低限必要な対策を施したレベル
電子署名法における認定認証業務において発行する電子証明書に基づいたリモート署名サービスが認レベル２
定認証業務の信頼性と同等の信頼性を達成するために必要なレベル
リモート署名サービスが欧州eIDAS規則における適レベル３ 格電子署名と同等の信頼性を達成するために必要なレベル

4

LangEdge,Inc.

リモート署名利用の流れ
本人確認（KYC/eKYC）
登録（鍵登録・認証要素発行）
利用認証（当人確認）

リモート署名ガイドラインのスコープ外
本人確認の保証レベル（IAL）は事業者で決めれば良い。
通常は認証局（CA）に依存する。
リモート署名ガイドラインのスコープ外
当人確認の保証レベル（AAL）は事業者で決めれば良い。

前準備（署名対象の用意）
レベル１：鍵認可処理を省略可能

鍵認可（署名意志の確認）

利用認証をもって鍵認可としても良いとなっている。

署名処理（署名鍵の利用）（レベル1.5：１要素認証要素が必要）
PIN等の要素を署名時に求める。

削除（利用終了）

レベル２：２要素認証要素が必要
利用認証のレベルは要求しない。

LangEdge,Inc.

5

リモート署名 登場人物（ロール）
1. Signer（署名者/エンドユーザ）
 リモート署名ではエンティティが人間なのでエンドユーザ。

2. SCA （署名クライアント/署名サービス）
 署名者の認可を受けて、署名を付与するサーバ。

3. RSSP （鍵管理サーバ/鍵リソースサーバ）
 SCAからの要求により署名鍵にて署名値を計算して返す。
 別サーバの場合にはアクセストークンを要求する。
 レベル２では署名者からクレデンシャル認可を受け取り、SADトークン（鍵認可トークン）の発行を行う。

4. CSP （クレデンシャル発行者/認可サーバ/OP）
 署名者（利用者）管理を行いOAuth/OIDC等の認証認可によりアクセストークンを発行するサーバ。

6

LangEdge,Inc.

レベル１ リモート署名 登場人物（ロール）の関係(１) 利用認証要求

アクセストークンと認可コードの発行。

(２) 利用認可コード

認可サーバ（CSP）(４) 利用認可コード(５) アクセストークン※ (３)にて可能なら鍵利用PIN等も渡す。

(３) 署名要求w認可コード
署名者（Signer）(８) 署名結果

署名クライアント（SCA）※ 別サーバならアクセストークンを提示。
※ 可能なら鍵利用PIN等を指定。

レベル１では利用者認可をもって鍵認可としても良い。
可能なら鍵認可にPIN程度は望みたい。

(６) 署名値要求(７) 署名値

鍵管理サーバ（RSSP）

7

LangEdge,Inc.

レベル１ リモート署名 （Authorization Code Flow）
SignerCSP

SCA
request service
redirect to AuthZ server

利用認証処理end user AuthN
redirect to service (AuthZ code)(AuthZ code)

request access token (AuthZ code)(access token)

request sign
request PIN
鍵認可処理
(PIN)

レベル１では鍵認可は必須では無いが利用をすることでレベル1.5に。
request(accesstoken)
requestsignsign(PIN+ accesstoken)(signature value)(signed doc)

SCAはConfidential Client
なので、Authorization
Code Flowを使うべき。

RSSP

8

LangEdge,Inc.

レベル２ リモート署名 登場人物（ロール）の関係(１) 利用認証要求(２) 利用認可コード

アクセストークンと認可コードの発行。

認可サーバ（CSP）(４) 利用認可コード(５) アクセストークン(３) 署名要求w認可コード
署名者（Signer）(12) 署名結果

署名クライアント（SCA）※ (６)と(１０)には同じ署名対象ハッシュ値も指定。

(６) SADトークン要求wアクセストークン(10) 署名値要求wSADトークン(７) 署名認可のSAD要求※ (７)と(８)はSCA経由の場合が多い。

(８) SAD(鍵活性化データ)※ SAD（鍵認可クレデンシャル）は2要素。

(９) SADトークン(11) 署名値
SADトークンの発行。
※ HSM利用必須

鍵管理サーバ（RSSP）

9

LangEdge,Inc.

レベル２ リモート署名 （Authorization Code Flow）
Signer

CSP

SCA

RSSP

request service
redirect to AuthZ server

利用認証処理end user AuthN
redirect to service (AuthZ code)(AuthZ code)

request access token (AuthZ code)(access token)

request sign

SADはRSSPが処理

request SAD Token (access token)
鍵認可処理

request SAD(SAD token)

2要素認証が必要。
CIBAやFIDO2の利用も可能。

request sign (SAD token)(signature value)(signed doc)

(SAD)

10

LangEdge,Inc.

SAD（鍵活性化データ） と SADトークン
SAD：Signature Activation Data
署名鍵を活性化するデータ（クレデンシャル）だが、トークンとして引換する場合にそのトークン自体をSADと呼ぶ場合がある。
ガイドラインでは「SAD」と「SADトークン」として分けている。
SADトークン（鍵認可トークン）は署名１回のみで有効であり、複数署名する場合にはSADトークンを更新して行く。
トークンと引換しない
RSSP

SCA

SAD + HASH

Signature ValueSAD Token

SAD Token + HASH
Signature ValueRSSP

SCA

RSSP

SCA

SAD + HASH

リモート署名ガイドライン

CSC API 定義

トークンと引換する

ReqData + HASH

credentials/authorize=SAD

これはトークン

SAD + HASH

signatures/signHash

Signature Value

11

LangEdge,Inc.

考察：ローカル署名の認証レベル（AAL）
ローカル署名では、手元に保有する秘密鍵（ICカードや証明書ストア格納）を利用して署名を付与する。これを認証的なレベル（AAL）のローカル認証として考えるとどうなるか？

 秘密鍵の「所有」で１要素は満たす。
 PINが必要であれば「知識」の２要素目も満たす。
つまり２要素認証と言えるのではないか。リモート署名に同等のレベルを要求するなら２要素認証（AAL2/AAL3）が必要となる。

＋所有知識

13

LangEdge,Inc.

参考：電子署名・電子シールとデジタル署名技術
名称（用途）

電子署名

電子シール（eシール）

タイムスタンプ

英語名称

eSignature

eSeal(Electronic Signature)(Electronic Seal)

Timestamp

自然人

法人（組織・部署）

署名者は自然人であり「本人性」を保証する
例：電子契約書

署名者は法人等であり「発行元」を保証する
例：レシート

署名者
（証明書）

説明
デジタル署名フォーマット（署名形式）

CAdES/XAdES/PAdES Digital Siganature Format
ISO 14533-1/2/3 プロファイル※ 電子署名と電子シールの違いは署名証明書のみ

時刻認証局（TSA）※ 信頼済みの第三者
時刻認証局によるサーバ署名であり「日時」を保証する
タイムスタンプトークン
RFC 3161※ デジタル署名の一種

 電⼦署名・電⼦シール・タイムスタンプにデジタル署名の技術・標準を利⽤することで完全性も保証することが出来る。
 デジタル署名は暗号技術による電⼦署名・電⼦シール・タイムスタンプの実現⽅法の１つであり、他の⽅法により実現することも可能である（例:⽴会⼈型署名）。
 デジタル署名は「本⼈性」「⾮改ざん性」「⽇時」をまとめてパッケージ化できる利点がある。またデジタル署名には検証⽅法も標準化されている利点もある。