はじめに、何故分解するのか
私はデジタルアイデンティティ・電子認証の世界で要素を解体…いや分解してレベル分けしたものが NIST SP 800-63 だと考えています。電子認証の要素が「身元確認」と「当人認証」に分解できることを示したことは大きいです。
では電子署名の世界で同じように要素に分解し、かつ電子認証と同じ言語で示すことはできないだろうか？実はこのテーマでもう何年も前からJNSAの電子署名WGでガイドラインを作成しています。沢山の専門家と共に検討してきてほとんど形になってきたので間もなく公開する予定です。今日はその中から特に電子認証と同様に電子署名を同じ言語で解体・分解するとどうなるか。と言うことを書きます。
補足：電子認証と電子署名
本題に入る前に、おそらくID厨には電子認証ってなんだよとなるかもしれませんね。電子認証と言う言葉はアイデンティティ業界では昨今あまり使われませんが、NIST SP 800-63においてもPart2まではタイトルが「Electronic Authentication Guideline」であり、Part3から「Digital Identity Guidelines」となった経緯があります。更にPart3において「Electronic Authentication」の定義は「Digital Authentication」の古い呼び方であり「情報システムに対して電子的に表現されたユーザーの Identity の確からしさを確立するプロセス」とされています。一方で「Digital Identity」はPart4において「特定のコンテキスト内でサブジェクトを一意に説明する属性または属性のセット」とされていますので、意味としては認証よりもアイデンティティに主眼が置かれた言葉となっているように思えます。
なお署名業界では近年になって、電子署名は目的用途や法的な意味で用いられ、デジタル署名は暗号を利用した電子署名の１種であり技術用途と整理しています。用途や法的な意味である電子署名とデジタル署名を区別していることに対比することを考えて、本投稿では「電子認証」を目的用途的意味として用いることにします。NIST SP 800-63 Part2までも身元確認（identity proofing）は含んでいることから、電子認証も身元確認と当人認証を包含していることにします。この辺りは異論のある方もいらっしゃいますと思いますがまあ本投稿ではそうしていると言うことでw
電子認証の解体
これは既にNIST SP 800-63で解体済みです。身元確認（IAL）と当人認証（AAL）が電子認証における要素となります。あれ？FALはどうなるの？と言う疑問が出ますよね。FALが保証しているのは認証結果連携だと考えています。これは認証自体ではなく連携なのでここでは対象外とします。
フェーズで分けると、登録フェーズに行われるのが身元確認であり、
利用フェーズで行われるのが当人認証であると言えます。
電子署名の解体
電子署名の要件は電子署名法から見ると、本人の意思と非改ざんの２つとなります。電子認証の身元確認と当人認証とは異なった要件に見えますよね。ここで電子認証側に寄って同じ言語に変換して行きます。
まず本人の意思ですが署名をプロセスつまり署名行為だと考えるとこれは身元確認済みの当人による認証あるいは認可と置き換えることが可能です。署名は当人がその文書について同意または承認する行為と言うことですね。当人性は当人認証で保証されるので、本人の意思とはほぼ当人認証と言えることになります。なぜほぼが付くかですが、電子署名の場合には文書の内容に関する同意や承認が必要になるからです。これから本人の意思は以下と解体します。
本人の意思 ＝ 内容確認 ＋ 当人認証（承認）
ここで１つの疑問が出ます。電子署名では身元確認は不要なのでしょうか？実は電子署名法が求めているのは作成者（署名者）本人の署名であることだけです。でも実際に電子署名をする時には例えばPKIであれば認証局（CA）が身元確認を行ってから電子証明書を発行しています。つまり電子署名法には明記されていませんが、実際には身元確認も必要となります。ですので本投稿では身元確認も電子署名の要件の１つとして採用します。電子署名法よりも本投稿の方が厳しい要件になっていると言うことですね。身元確認の内容自体は電子認証でも電子署名でも変わりません。
最後に非改ざんですがこれは署名から一定の時間を経た後に署名文書が署名時から変更されていないことが求められます。つまりプロセスでは無く署名文書（データ）について後日検証可能であることを求めています。実は電子署名では本人の意思に関しても証拠として後日の第三者による検証プロセスにおいて保証可能であることが求められます。検証プロセスでは署名文書と本人性と非改ざんであることを検証可能な証拠から検証して確認できる必要があります。この検証可能な証拠を署名データと呼ぶことにします。
認証と同様にフェーズで分けると、登録フェーズに行われるのが身元確認であり、利用（署名）フェーズで行われるのが内容確認＋当人認証（承認）であり、検証フェーズで行われるのが署名データ検証となります。
電子署名と電子認証の比較
文字による説明ばかりで疲れますね。ここで表にしてまとめてみましょう。
| フェーズ | 電子認証 | 電子署名 |
|---|---|---|
| 登録 | 身元確認 | 身元確認 |
| 利用 | 当人認証 | 当人認証（承認）＋内容確認 |
| 検証 | --- | 署名データ検証 |
登録フェーズは電子認証でも電子署名でも身元確認が必要であり同じと言えます。利用フェーズでは電子署名には電子認証で必要な当人認証に加えて承認する為の内容確認が追加で必要となります。検証フェーズは電子認証には存在せず電子署名特有の要件と言えます。電子署名の方が要件が多いと言うことですね。
電子署名と電子認証の目的
そもそもになりますが電子署名と電子認証の目的とは何でしょうか？電子認証は、端末（PC）の今いるのは誰なのかの本人性の確認です。プロセスにおける本人性確認と言っても良いでしょう。電子署名は、過去に行われた署名を検証して本人性と非改ざんの確認です。データにおける本人性確認と言っても良いでしょう。これを整理すると以下となります。
| 項目 | 電子認証 | 電子署名 |
|---|---|---|
| 時間 | 現在 | 過去 |
| 対象 | プロセス | データ |
| 非改ざん | --- | 必要 |
どちらも本人性の確認なので混同されがちで、PKI爺は「電子署名の方が電子認証よりレベルが上だ！」とか言いがちですがそんなことはありません。要件や目的が異なる別の概念です。
足りない要件を足せば電子認証を使った電子署名も可能となります。電子認証に足りないのは署名データ（証拠）と非改ざんの保証です。どのような電子認証のプロセスで署名したのかまたその時の署名文書が何であったかを記録して保存しておけば電子署名にできます。これを私は認証記録型電子署名と呼んでいます。
逆に電子署名を使った電子認証の場合には要件を省くことで可能となります。本来検証は過去の署名データに対して行いますが、リアルタイムに検証して検証が成功したら署名データを捨てることで電子認証となります。この時に署名文書は何でも良いので通常はチャレンジデータと言う認証要求者がその時生成したデータを利用します。
署名保証レベル
それでは某電子署名WGで作成しているNIST SP 800-63風に整理した電子署名の各要件の保証レベルを見てみましょう。
| 署名保証レベル | 説明 | SP 800-63との関係 |
|---|---|---|
| SIAL 署名者身元保証レベル Signer Identity Assurance Level |
署名者の身元確認による本人性の保証 | IALと同じ |
| SPAL 署名プロセス保証レベル Signing Process Assurance Level |
署名時の当人性と署名意思確認の保証 | AALとほぼ同じ |
| SDAL 署名データ保証レベル Signature data Assurance Level |
署名データ自体の信頼性に関する保証 | 電子署名独自 |
これらの署名保証レベル（SxAL）を解説するガイドラインを執筆中です。本当は2025年末までに出すつもりだったのですが間に合わないので、2025年度末までに延長しました。…はい…年度末（2026年3月末）までには公開します（がんばれヲレ）。本投稿は予告編と言うことで！
署名データ保証レベル
署名独自の保証レベルである署名データ保証レベル（SDAL）の話を少しだけしておきましょう。Verifiable（検証可能）と言う言葉が最近良く使われます。デジタル証明書として注目されている VC（Verifiable Credential）等ですね。検証可能とは「第三者が実行できる検証手順とその根拠が定義されている」と理解しています。
電子署名の場合には、署名した証拠としての署名データが検証可能であることを求められます。SDALとは署名データ自身がどれだけ検証可能であるかを示すレベルです。デジタル署名とPKIを利用したローカル署名方式では、検証可能であるために色々な標準化や認定制度が定められてきました。X.509・RFC 5280・長期署名（ISO 14533）であったりWebTrust認定・認定認証局であったりと言う部分です。
非PKIの電子認証を使った電子署名である認証記録型署名方式では署名データはログファイルであったり独自記録であったりと言うことで検証手順が明確にされていないケースが多いのです。検証可能かどうかと言う意味ではPKIローカル署名と認証記録署名ではレベルの違いがあると言うことになります。以下に公開予定の資料からSDALの部分のみを抜粋します。
| レベル | 説明 |
|---|---|
| SDAL1 | 署名事業者から何らかの署名者の本人の意思（承認）と非改ざんに関する、第三者による検証が可能な署名データ（属性情報）が提供できること、および何らかの署名時刻も提供できること。 |
| SDAL2 | 標準化または事前に定められた検証手順に従うことで署名者の本人の意思（承認）と非改ざんの第三者による確認が可能な署名データ（属性情報）が提供できること。および信頼された署名時刻が確認可能となること。 |
| SDAL3 | SDAL2に加えて本人性と署名時刻に対して信頼された第三者組織による保証があること。 |
署名時刻は電子署名の要件には入っていませんが重要です。いつ承認したのかと言うのは証拠して重要であるためです。このためにSDALでは署名時刻に関する要求を加えてあります。
トラスト設計（TbD：Trust by Design）
正直に言ってトラストと言う言葉は使いたくありません。それはトラストの定義が人によって異なることが多く誤解を招くことがあるためです。しかしながら広義の意味であればトラストを単に信頼性とすることも多いのでついつい使ってしまいます。ここでは単に信頼性と言う広義の意味でトラストと言う単語を使います。
トラストを保証する技術として電子認証と電子署名があると考えています。プロセスについての本人性を保証する場合には電子認証を、データについての本人性＋非改ざんを保証する場合には電子署名を使うことになります。守りたいものがプロセスなのかデータなのかと言っても構いません。
| 技術 | 保証内容 |
|---|---|
| 電子認証 | プロセスについての本人性を保証する |
| 電子署名 | データについての本人性＋非改ざんを保証する |
システム設計において何らかのトラストが必要になる場合にはこの電子認証と電子署名を使ってプロセスやデータを守ることになります。であるならシステム設計の最初からトラストを意識して検討すべき、つまりトラスト設計を組み込みましょうと言うことを提唱したいと考えています。これを最近流行りのPbD：Privacy by DesignをもじってTbD：Trust by Designと呼びたいと考えています。言葉は定着しなくてもシステム設計時に最初に何のトラスト（信頼性）が必要なのかまたそのトラストのリスク管理をすることは基本として流行って欲しいです。
残念ながらトラスト設計の整理はまだできていません。今年度出す予定のガイドラインでも概念的な説明のみとなります。これは次のステップかなと考えているので来年度以降のテーマにする予定です。
最後に、業界を繋げたい
トラスト設計にあるように電子署名と電子認証のどちらかまたは両方が必要となった場合に、要件を整理して適切な技術を使えるようにしたいのです。ですがID業界とPKI業界には壁があると言うか、少なくとも言語的な壁はあると感じています。なので同じ言語で同じように使えるようにしたい。それが私の目標です。まずは今年度内にJNSA電子署名WGから「署名保証ガイドライン」を出す予定です。内容はNIST SP 800-63を参考に、電子署名の要件整理、色々な電子署名方式の説明、署名要件の保証レベルの定義、署名のリスク管理、等となります。出せるかなあ…いや出さねば！年度末に向かって頑張りますw それではこれが今年最後の投稿です。皆様良いお年を！
以上