認証と署名の整理をしましょう（またかよ）

はじめに

　去年の「Digital Identity技術勉強会 #iddanceAdvent Calendar 2022」でも「認証と署名は何が違う？ ～マイナンバーカードを例に～」として認証と署名の話をしました。実は今年も必要に迫られて認証と署名の整理をしてきてある程度まとまったかな…と言うことで今年も再び書かせてください！また署名業界では新たに電子シール（eシールとも呼ばれる非自然人/組織の電子証明書によるデジタル署名）の検討が進んでいます。なので署名も電子署名と電子シールに分けて整理をしてみます。年末の忙しい時期ですが楽しんでご笑読ください。認証と署名の整理についてはこれで最後にしたい…なぁw

デジタルアイデンティティ

　さてまず認証と署名を比較するとはどういうことかを整理しましょう。認証…と言うよりも技術全体を示すのであれば最近はデジタルアイデンティティ（Digital Identity）と言った方が良いのでしょうか。これも「NIST SP 800-63: Digital Identity Guidelines」が有名になり、デジタルアイデンティティの要件を整理したことが大きいと考えています。NIST SP 800-63-3また最近ドラフトが出ているSP 800-63-4では整理として3つの要素に整理しており、それぞれIAL/AAL/FALと言う保証レベルを整理しています。

番号	タイトル	保証レベル
SP 800-63A	Enrollment & Identity Proofing	IAL
SP 800-63B	Authentication & Lifecycle Management	AAL
SP 800-63C	Federation & Assertions	FAL

　3つの保証レベルとは何を保証しているのでしょう。「IAL:身元確認保証レベル」「AAL:当人認証保証レベル」「FAL:認証連携保証レベル」となります。

保証レベル	英語名	保証内容
IAL	Identity Assurance Level	身元確認
AAL	Authentication Assurance Level	当人認証
FAL	Federation Assurance Level	認証連携

　「認証連携/Federation」は認証サービス1つだけでは必要がありません。ですので「認証」の本質とは少し違うと考えています。この記事では「認証」を残る2つの「身元確認/Identity」と「当人認証/Authentication」を加えたものとします。

認証の整理

　先に書いた通りこの記事では認証を身元確認＋当人認証と整理します。

　「認証」＝「身元確認/Identity」＋「当人認証/Authentication」

身元確認（Identity）の定義
登録時に申請者が提示する属性情報の確かさを確認して身元（本人性）を確認すること。

当人認証（Authentication）の定義
端末の前にいる実体がサービス側が認識するどのIdentityと紐付いているかの確証を得ること。

　両方を合わせると「認証とは端末の前で操作している自然人が身元確認済みの当人であることを保証する技術である。」と整理します。もっと乱暴な言い方をすれば「認証とは端末の前にいる自然人の本人性を保証する技術」と言えます。ID連携しないのであれば保証レベルとしてはIALとAALが使われます。

署名の整理

　では署名とはどのようなことを保証する技術でしょう？日本には電子署名法と言う法律があります。そこでは電子署名を以下のように定義しています。

電⼦署名法 第２条第１項 の電⼦署名の定義
「デジタル情報（電磁的記録に記録することができる情報） 」について⾏われる「措置」であって以下のいずれにも該当するもの。
(1) 当該情報が、当該措置を⾏った者の作成に係るものであることを⽰すためのものであること（同項第１号）
(2) 当該情報について、改変が⾏われていないかどうかを確認することができるものであること（同項第２号）

　ここでは電子署名を「措置」としています。これを分かりやすく言えばプロセスだと言えます。その上で、(1)においてデジタル情報に署名者本人の意思が確認でき、(2)においてその時から改ざんがされていない、ことを保証する必要があると言えます。うーん…分かりにくいですねw もう少し分かりやすく整理すると「署名とはデジタル情報の本人性（意思）と非改ざん性を保証する技術」と言えます。

認証と署名が何を保証しているかの整理

技術	保証
認証	端末の前にいる自然人の本人性を保証
署名	デジタル情報の本人性（意思）と非改ざん性を保証

　こうして並べてみるとどちらも「本人性」と言う共通項があります。どちらも本人性を保証する技術ではあると言うことですね。例えば電子申請時に「誰が申請しているのか？」を認証と署名のどちらでも保証することが可能となります。この辺りで混乱を生じます。レガシーなPKI業界の人たちは「認証よりも署名の方がレベルが上」と言ったり、ID業界の人たちは「署名なんて面倒だし認証で十分」みたいなことを言ったりします。ちょっと乱暴ですね。もっとロジカルに違いや使い方やリスクを判断しましょう。と言うのがこの記事の目的です。（長い前振りだなw）

認証と署名の比較

　まず先に挙げた「本人性」以外の箇所を確認してみましょう。認証では「端末の前にいる自然人」に関する「本人性」です。つまりリアルタイムで現在端末の前にいるのは誰かと言うことを保証します。ここで大事なのはリアルタイムと言うことと端末で操作を要求できることです。言い方を変えると「リアルタイムのプロセスにおける本人性の保証」です。一方で署名では対象がデジタル情報であり時間の概念は入っていませんが、あえて言えば「過去に署名が付与されたデータの本人性の保証」になります。なお署名は対象データの保証である為に本人性以外に非改ざん性も保証する必要がありますが、認証はプロセスなので別途通信経路の非改ざん性の保証は別途必要となります。通常はTLS通信等の暗号通信で保証することが多いと思います。逆に言えば署名では流通経路が保証されていなくてもデータの保証出来ると言うことになります。署名では意思の確認（否認防止）も必要ですが、内容を確認して本人のみが付与可能な署名を付ける言うプロセス（措置）で保証しています。認証における意思の確認は画面に表示されたボタンをクリックしたことで意思確認をします。これを整理すると以下になります。

	認証	署名
対象	プロセスの保証	データの保証
時間	リアルタイムの保証	過去まで保証(時差ありも可)
内容	通信経路の保証	非改ざん性の保証
意思	端末操作による保証	署名措置による保証

　技術的要件的に認証と署名の違いは明確になったと思います。ではどのように使い分ければ良いのでしょうか？簡単に言えば用途に求められるリスクによって選択すれば良いと考えます。

認証の用途

　認証はプロセスの保証です。端末の前にいる利用者を特定することがリアルタイムに可能です。利用者を特定した後にアクセストークンを発行することでセッションを張ることができます。セッション中の操作は認証された本人の操作とみなすことができます。例えば電子申請時に認証を使えばセッションを張って「申請する」ボタンをクリック操作させることで利用者の申請意思をリアルタイムで確認できます。しかし後日その意思を確認する為には操作ログのような記録が必要となります。また記録は改ざんや偽造の可能性もゼロではありません。そう考えると後から否認された時にコストダメージが無いような軽い用途であれば認証だけでも良さそうです。

署名の用途

　署名はデータの保証です。署名付きデータを検証することで後からいつでも本人の意思を確認できます。例えば電子申請ではイメージとしては申請用紙に事前に記入と押印をして提出するやり方をそのままデジタル化できます。署名付与は申請前（直前も可）に行っておき、署名検証は後からいつでも可能となります。また暗号を使ったデジタル署名を使えば改ざんも検知できます。つまり申請者の申請意思と共に申請時からデータが改ざんされていないことも後日も含めて保証できます。これは否認された場合に裁判が必要になるようなリスクがある場合に向いた技術と言えます。

　署名は安全ではない経路を経由しても保証ができます。ですので例えば電子申請時に第三者が提供する添付データがあるような場合でも有効です。つまり間接的にデータの本人性の保証が必要となるような用途にも向いています。

認証を使った署名

　工夫をすれば認証を使った署名も可能です。リアルタイムの本人確認は認証で出来るので後日でも検証可能にすることと改ざん防止が出来れば良いことになります。後日検証可能にする為には認証の操作ログを記録しておきいつでも提示できるようにすれば良いでしょう。改ざん防止は信頼されたサーバーに保管したりハッシュ値を取っておいたりすれば対応できそうです。これを私は認証記録型署名と呼んでいます。

　もう1つ認証を使ったリモート署名（当人署名型）と言う方式があります。クラウド上に預けた署名鍵を認証により当人認証をした上で利用する方式です。リモート署名では最初の身元確認がちゃんとしており認証要素をちゃんとバインディングしてあれば、後は電子証明書が自動発行出来れば普通のクラウドサービスとして従来のローカル署名と同じく当人署名型の署名の利用が可能になります。リモート署名では認証インフラが重要でありクラウド時代の活用が期待されます。

署名を使った認証

　署名は本人保証の検証を後日可能にする技術ですがリアルタイムに検証することも可能です。サーバーからチャレンジデータを提供しておき利用者はチャレンジデータにデジタル署名をしてサーバーに返すことで認証とすることができます。サーバーでは検証が出来れば本人であることを確認出来ることになります。これは署名対象の内容を確認していないので署名では無く認証としての用途となります。例えばマイナンバーカードの利用者証明用証明書はこの方法により認証を実現していることになります。

認証と署名のまとめ

　認証も署名も本人性を保証する技術と言う点は共通しています。ですので運用や他の技術を組み合わせることで「認証を使った署名」も「署名を使った認証」も可能である為にややこしくなると言うことですね。ただ一般のクラウドサービスを利用するだけであればほぼ認証で十分と言えます。否認防止が重要であれば署名を使うことを検討しても良いでしょう。また間接的に本人性を保証したデータを提供する場合にも署名は有効です。使いたい用途にどのようなリスクがあるのかそのリスクを防ぐまたは小さくする為に認証と署名のどちらが向いているかを考えて検討することが良いと考えています。またリモート署名と言う方式を利用すれば認証インフラの上に署名サービスの構築が可能となります。これからの署名エンジニアは認証の知識が必須ですし、各種のトラストサービスを構築する上で認証と署名の両方の知識があると検討の幅が広がります。食わず嫌いにならず両方の勉強をしましょう。

---

署名の保証レベル

　認証にはNIST SP 800-63があってIALやAALの保証レベルがあってレベルの確認が容易です。では署名の保証レベルもあっては良いのではないでしょうか？と言うことで実は今「署名保証レベル」まとめようとしています。まだ完全にできてはいないのですが簡単に概要だけ説明しましょう。

　認証の保証レベルは、「認証」＝「身元確認」＋「当人認証」でした。では署名の保証レベルはどうでしょう？

　「署名」＝「署名者」＋「署名認可」＋「署名データ」

　の3つになると整理しています。署名者の保証レベルをSIAL（Signer Identity AL）と、署名プロセスの保証レベルをSPAL（Signing Process AL）と、署名データの保証レベルをSDAL（Signed Data AL）と名付けようとしています。SIALは署名者の身元確認（これはIALとほぼ同じ）のレベルです。SPALは署名時のプロセス（ほぼ認証プロセスと同じなのでAALとほぼ同じ）のレベルです。SDALは後から検証によって署名者を保証する「証拠」ですので署名独自の保証レベルと言えます。Signer・Signing・Signedの3つの保証レベルが署名では大事と言うことです。

番号	タイトル	保証レベル
SAG:2024-A	署名者の保証(身元確認) / Signer Identity	SIAL
SAG:2024-B	署名時の保証(署名認可) / Signing Process	SPAL
SAG:2024-C	署名後の保証(署名検証) / Signed Data	SDAL

　正直を言って署名保証ガイドラインはNISTのSP 800-63を参考にしていますし参照もしています。またリスクにより保証レベルの選択を示す面も同じように署名用の記述しようと考えています。欧州だと署名はeIDASによりレギュレーションが決まっているので保証レベルのニーズは低く、米国だと裁判に勝てれば良く標準化された署名が少ないのでやはりニーズは低いのでしょう。日本は現在色々な署名方式が使われているのでニーズが高いと考えています。

　署名保証レベルの検討はJNSAの電子署名WGの保証レベルTFと言うところでおこなっています。既に要約版を2022年の夏に公開しています。公開後にも検討が進んでいますので要約版と上記のSigner・Signing・Signedの整理とは既に内容が乖離していますが、2024年には整理した署名保証ガイドラインを公開しようと作業を進めています。頑張っていますのでもう少しだけお待ちください。

---

電子署名と電子シール（eシール）

　すみませんまだ終わりませんw 次は最近名前を聞くことも増えた電子シール（eシール）と電子署名の違いもついでにまとめておきましょう。まず電子署名と電子シールは技術的には暗号を使ったデジタル署名を使う全く同じものです。あ。用語ですが電子署名は法的だったり用途の用語だとしており電子シールも同様です。デジタル署名は公開鍵暗号を使ったもので技術用途となります。さて電子署名と電子シールで異なるのは利用するX.509電子証明書の所有者（Subject）が自然人なのか非自然人（通常は組織や法人）だけとなります。技術としてはどちらもデジタル署名とPKIを使うことになります。イメージとしては、電子署名の電子証明書は印鑑登録された個人印（会社の場合には登記されている代表印）であり、電子シールの電子証明書は会社印（いわゆる角印）であると言えます。しかし自然人の電子証明書を使って電子シール的な利用をするようなケースがあります。つまり電子証明書の種類では無く用途が違うケースがあると言うことになります。

　電子署名は上で認証と比較している署名と言うことになります。つまり本人の意思と改ざん防止の実現です。一方で組織等の場合には意思と言うよりも組織が発行した文書であることの内容の証明に使う用途となります。否認防止的な用途の署名を「承認署名」と、内容保証的な用途を「証明署名」と呼ぼうと考えています。

種類	所有者	一般的な用途
電子署名	自然人(署名者)	主に承認署名
電子シール	非自然人(組織/法人等)	主に証明署名

証明署名

　承認署名については先に書いた「署名」の用途がそのままとなります。つまり主に否認防止的な側面が大きいことになります。では電子シール的な証明署名とは何が目的かと言えば発行元の保証の側面が大きいと言えます。Webサイトをブラウザに開く時にサーバー証明書を使っていますが、これは利用しているサイトの正当性を保証しています。証明署名は同様にデータ（ドキュメント等）の発行元の正当性を保証すると整理しています。この場合は個人と言うよりも組織が保証した方が自然ですよね。

　自然人の電子証明書であっても証明署名を行うような例としては例えば大学等の卒業証明書をデジタル発行する場合に学長が個人としてデジタル署名するケースがあると思います。実際に現在は電子シールが普及していないので自然人の電子証明書で電子シール的な証明署名をしているケースがほとんだと思います。これを電子シールも導入して使い分けをちゃんとしましょう、と言うことだと考えています。

種類	解説
承認署名	電子署名法が認めている否認防止を目的とした用途 ※ 通常「署名」と言えばこちらの用途
証明署名	発行元を保証する（証明されている）用途 ※ 今後普及が見込まれている用途

　承認署名なのか証明署名なのかを見極めるには署名時に内容を確認（承認）しているかどうかで判断ができます。証明署名はルールを決めて自動署名することになります。その意味では例えば請求書に電子シールでデジタル署名するような場合には内容を確認しているはずですので承認署名の要素が強いことになります。ここで「強い」と言う言い方をしましたが実際の利用シーンでは承認署名的な面と証明署名的な面は共存していることが多いはずです。どちらが強いかと言う程度の判断にはなります。

　現在世の中では事業者型署名（立会人型署名とも呼ばれる）が使われていますが、事業者（立会人）がデジタル署名を自動的に付与しているのでこれだけだと証明署名です。承認署名にする為には本人の意思を確認できる必要がありますので例えば認証時の操作記録であったりと言う他のデータが必要になります。本人性に関してはこちらのデータの方が重要となります。

　承認署名はその性質上ドキュメントに付与されることが多いと予想されます。つまりPDFファイルが対象になることが多いでしょう。アドビのReaderを前提にすることになりますのでAATL認定と呼ばれるアドビの認定がある電子証明書の利用が望ましいでしょう。

---

全体まとめ

　まずここまで説明して来た認証・署名（承認署名）・証明署名を表にして比較してみましょう。

	認証	署名 (承認署名)	証明署名
保証対象	プロセス保証	データ保証	データ保証
本人性確認/検証	リアルタイム	時差あり 経路外取得も可能	時差あり 経路外取得も可能
目的	端末前の当人認証 ※ セッション保証	内容の承認 (意思) ※ 否認防止・改ざん防止	発行元の保証 ※ 内容証明・改ざん防止
署名認可	---	内容確認と署名認可が必要	自動署名が可能
主な用途	サービス認証・ID連携	電子署名	電子シール (eシール)

　ここまで読めば分かると思いますが認証と署名は異なる目的と用途で使われるものです（え？分からない？それは私の責任ですごめんなさいw）。どちらの安全性が上とか下とかはありません。きちんと身元確認と当人認証を行っている認証の方が、ろくに身元確認をせずに使われる署名よりもはるかにトラスト（信頼）できます。認証も署名もリスクを分析して適切な保証レベルを選ぶことが重要です。

　クラウドサービス、特にトラスト（信頼性）が必要な場合には認証と署名を組み合わせて使うことになるでしょう。その時に認証とはどのような用途と目的なのか、署名とはどのような用途と目的なのか、をロジカルに分析して適用できる必要があります。この記事も完全ではありませんがそのような時の一助になれば幸いです。

　この記事は「Digital Identity技術勉強会 #iddanceAdvent Calendar 2023」に参加しているのでデジタルアイデンティティの関係者の閲覧が多いことと思います。ID系の方には署名/PKI系の話題はつまらなかったかもしれませんごめんなさい(^^;; ま…まあトラスト系と言う意味では仲良くしましょう！いやしてください！お願いしますw

　それでは皆様良いクリスマスと年末を～！