「トラスト」について考える

はじめに

メリークリスマス！

私は長年セキュリティ界隈で働いて来ましたが、ここ最近にわかに「トラスト」が脚光を浴びている印象があります。その割に、セキュリティが専門でない方にとっては、具体的に「トラスト」とは何を指しているのか分からないと言う方も多いのではないでしょうか。そこで、この記事では、最近のセキュリティアーキテクチャの変遷も踏まえて、「トラスト」に関する私なりの解説を加えてみたいと思います。

「トラスト」の定義

まず、この記事の読者の皆さんは、少なくともインターネット上のサービスやデジタル製品（スマホアプリ等）の開発に携わる方が大多数でしょうから、特に「デジタルトラスト」を対象とします。この言葉でググって見ると、

• デジタルトラスト：デジタル技術やサービス（それらを提供する組織）が、全ての利害関係者の利益を保護し、社会的な期待や価値を擁護することに対する個々人の期待（世界経済フォーラム¹）

• 事実の確認をしない状態で、相手先が期待したとおりに振る舞うと信じる度合い（デジタル庁Trusted Webホームページ²）

等の定義が出てきます。他にも沢山の定義や解説が出て来るのですが、個人的には上記が一番腹落ちします。特に、後者に関しては、2019年1月の世界経済フォーラム年次総会（ダボス会議）にて、当時の安倍首相が「DFFT（Data Free Flow with Trust：信頼性のある自由なデータ流通）³」を提唱して以来、デジタル庁を中心として推進されているIT政策の目玉の一つとなっています。しかし、エンジニア的には、「それってどう実現・評価したら良いの？」と悩んでしまいますよね。そこで、大きく間違わない程度に3分類して詳細化しようと思います。

まず、インターネット上ですから、相手の顔は見えません。したがって、上記の「組織」や「相手先」の実体が、本当に彼らが名乗るような組織（法人）や個人なのか？と言うのが最初の課題です。いわゆる認証（Authentication）の問題ですね。その「信じる度合い」があるとのことなので、一言で「認証」と言っても、その手続きや方式（技術）によって、認証元が認証先を信じる度合いやレベルが違って来ると言うことです。一旦これを「IDトラスト」と定義してみます。

次に、相手の認証が出来たとして、相手から受け取ったデータが本当に相手の作成したものか？または途中経路で不正に書き換えられていないか？等の課題があります。これを「データトラスト」と定義します。

最後に、これが一番難しいのですが、上記の「全ての利害関係者の利益を保護」する能力があるか、または「相手先が期待したとおりに振る舞うと信じる」に足るかと言う課題です。「利害関係者の利益を保護」には、様々な意味が含まれていそうです。例えば、強固なセキュリティ保護の実装と体制の整備もあるでしょうし、プライバシーの保護に関しても同様です。組織が上場企業であれば、財務報告に係る内部統制が確立されているかと言う意味もあるでしょう。「振る舞い」に関しても同様です。この課題に対しては二つのアプローチが考えられます。一つは、相手方の組織において、セキュリティやプライバシーの保護、内部統制等が確立されていることを、何らかの基準に従って外部監査を受けて第三者認証を取得してもらい、それを参照すると言うアプローチです。セキュリティならISMS（情報セキュリティマネジメントシステム。ISO/IEC 27001）認証、プライバシーならPマーク、サービス事業者の内部統制ならSOC（System and Organization Controls）1/2等が考えられます。ただし、これらのデジタルな認定証は未だ存在しないと思われますので、相手方の組織がホームページ等にそれらの認定を取得している事実を公表し、それを自ら確認すると言う手間が生じます。

もう一つのアプローチは、上記の「振る舞い」を、特定のサービス（を実現するソフトウェア）に関するものと捉え、当該ソフトウェアのセキュリティが確保されていることや、利用者が期待する要件に対して正しく実装されていることを、何らかの形で保証し、利用者がそれを確認することです。勿論、完璧な保証は不可能ですので、サービス提供側が要求仕様を正しくセキュアに実装するソフトウェア開発プロセスを定め、その証跡を取得し先ほどと同様に何らかの第三者認証を取得すると言うのが一案です。ただし、個別のソフトウェアやサービスに対して第三者認証を取得していては、膨大なリソースとコストが掛かると言う課題は残ります。何らかの基準でソフトウェアの品質やセキュリティを検証し、その結果を利用者が参照するとしたら、例えば組織としてセキュアな開発プロセスを定義し、そのプロセスに沿って正しく開発されたソフトウェア（部品）には検証の証跡とセットでデジタルな保証書を付すようなことも考えられます。これを「ソフトウェアトラスト」と呼ぶことにします。

そもそもの前提知識～公開鍵暗号方式のおさらい～

さて、上記で3つのトラストを定義させて頂きました。勘の良い方ならお察しかと思いますが、これらを実現する一つの要素技術が公開鍵暗号となります。そこで、これを機に公開鍵暗号方式のおさらいをしてみましょう。

個人的に、公開鍵暗号方式は、今日のインターネットやデジタル経済の隆盛をもたらした、世紀の大発明だと思っています。特に、データ（実用的には暗号鍵）の暗号化とデジタル署名の両方を実現する、RSA暗号の貢献は非常に大きかったと思います。RSA暗号の発明以前にも、第二次世界大戦前から共通鍵暗号方式は存在していました。計算機科学界のノーベル賞とも呼ばれる「チューリング賞」で有名なアラン・チューリングが、第二次大戦中にナチス・ドイツの共通鍵暗号「エニグマ」の解読に従事していたと言うのは有名な話です。「イミテーション・ゲーム」と言う映画にもなっていますので、興味のある方は一度ご覧になることをお勧めします。

警告
次の段落はネタバレを含みますので、これから映画を見る方はご注意下さい。

この映画の中でも出てきますが、共通鍵暗号方式の課題は、通信相手の組み合わせ毎に、別々の暗号鍵（共通鍵）が必要となるため、システム全体としての管理が煩雑な点と、通信を開始する前に共通鍵を合意する必要があるため、その配送が難しいと言う点です。「共通鍵を配送するための暗号化を行うための共通鍵は・・・」と、無限ループに陥ってしまいます（苦笑）。映画の中では、確かラジオ放送の天気予報の中にキーワードが仕込まれていて、それに従って「エニグマ」の共通鍵を調整すると言う、暗号オタクにとっては堪らないエピソードが含まれていました。共通鍵暗号の課題を非常に上手く解決していたように思えるのですが、アラン・チューリングのような天才の前では無力になってしまう、と言うことですね。

そして、公開鍵暗号、特にRSA暗号は、まさに上記の暗号鍵配送の課題をクリアしつつ、データの暗号化だけでなくデジタル署名まで実現する仕組みです。以下のように、数学的に対応関係のある公開鍵と秘密鍵と言う鍵のペアを生成し、その名の通り「公開鍵」は広く公開して、自分宛のメッセージを暗号化するために利用してもらいます。一方で、「秘密鍵」は誰にも見られないように秘密にしておいて、自分宛のメッセージを復号するために用います。これ以降、公開鍵暗号方式に関する説明のために、IPA（情報処理推進機構）の「PKI 関連技術情報」から図を多数引用させて頂きます⁴。

この、数学的に対応関係のある二つの鍵ですが、公開鍵から秘密鍵を導出するのが極めて難しいと言うのがポイントとなります。RSA暗号の場合は、大きな合成数（素数の積）の素因数分解を効率的に解くアルゴリズムが存在しないと言うところに、その安全性を依拠しています。少し話は脱線しますが、RSA暗号や他の主要な公開鍵暗号方式の一つである楕円曲線暗号には、（量子ゲート型の汎用的な）量子コンピュータにより効率的に解読できるアルゴリズムの存在が知られています。したがって、量子コンピュータでも解けない新しい公開鍵暗号方式（格子暗号等）が「耐量子計算機暗号」と呼ばれ、研究・開発が進められています。最近も今年の8月に、NIST（米国立標準技術研究所）が3種類の耐量子計算機暗号を標準として採択しました。

繰り返しになりますが、公開鍵暗号方式を用いたデータの暗号化は、以下のように通信相手の公開鍵を用いることにより実現されます。

ただし、実用上は、公開鍵暗号方式は計算処理の負荷が重いため、暗号鍵（共通鍵）の交換に用いて、実際のデータの暗号化には共通鍵暗号方式を用いることが多いです。Webサイト等への暗号化通信で広く用いられるTLS/SSL（以下、単にSSLと記述）プロトコルの暗号化も、この方式で行われます⁵。

一方で、データへのデジタル署名は、逆のやり方で行われます。すなわち、秘密鍵を持っているのはその本人だけなので、秘密鍵で変換（署名）されたデータを、公開鍵で検証出来るとしたら、そのデータはその本人が作成したデータであり、かつ途中経路で不正に変更されていないことが証明できると言う訳です。更に言うと、後からその本人が「そんな署名をした覚えはない」と言っても、否認できないことになります。これは、先ほど説明した「IDトラスト」と「データトラスト」を実現するための、極めて優れた性質となります。以下に、暗号化とデジタル署名の両方をまとめた図を示します。

友達の友達は、みな友達だ！～PGP暗号の鍵共有～

前の章で、公開鍵暗号方式の発明により、暗号鍵配布の問題が根本的に解決したかのように説明してしまいましたが、実はそうでもありません。そもそも、インターネットのような非対面の世界で、会ったこともない通信相手の公開鍵をどうやって入手するのか？と言う問題が残ります。公開鍵暗号方式を早期に実装して利用可能としたのは、PGP（Pretty Good Privacy）暗号だったと思います。PGPでは、自分の秘密鍵や複数の通信相手の公開鍵を「鍵束」として管理します。更に、公開鍵だけを抜き出して、公開鍵ファイルを作り、仲間内で共有するようなことが行われていました。一番確実なのは、フロッピーディスク（Z世代に分かるかな？！）により、身近な友人から公開鍵ファイルを手渡しで入手し、遠く離れた顔の見えない相手と、PGP暗号による送信データ（この当時は主にメールやファイル）の暗号化やデジタル署名が行えるようになることでした。または、知り合いからメーリングリストに招待してもらって、そこで共有されている公開鍵ファイルを入手することもあったと思います。つまり、「友達の友達は、みな友達だ！」とばかりに、昭和世代には懐かしいお昼の番組の世界観ですね。

PGP暗号（GPGやOpenPGP）は、手軽なデータ暗号化とデジタル署名のツールとして、未だに使われていますが、上記のような相手の顔が見えない状況における公開鍵の配布・共有に課題を残しています。つまり、「信頼の基点」すなわち「トラストアンカー」をどうするか？と言う問題です。

中央集権型（認証局の階層構造）のPKI

そこで登場して来たのが、公開鍵証明書（標準規格である、ITU-T X.509⁶から、X.509証明書と呼ばれることもありますが、以下、単に「証明書」と呼びます）を発行する電子認証局（Certificate Authority。以下CA）による、公開鍵暗号基盤（Public Key Infrastructure。以下PKI）となります。

この基盤の利用者（図中では加入者）は、まず公開鍵と秘密鍵のペアを生成します。それをCAに提出し、CAは何らかの身元確認（組織に対する場合は実在性確認）を行った上で、加入者の属性情報と公開鍵に、CAのデジタル署名を付した「証明書」を発行します。CA自身も公開鍵と秘密鍵、もっと言うとCA自身の証明書を保有することがポイントとなります。

次に、証明書を取得した人が、自分宛のデータを暗号化してもらうために公開鍵（証明書）を提示したり、自分のデータにデジタル署名を付して送信する場合の、受信者側の動きを説明します。

受信者（図中では証明書利用者）は、送信者（図中では証明書所有者）の証明書に付されたCAのデジタル署名を、CAの証明書に含まれた公開鍵で検証します。しかし、ここでもPGP暗号のときと同じ問題にぶち当たります。このCAの証明書はどうやって入手するのか？それは本当に本物のCAの証明書なのか？と言う問題です。

それを解決するのが、前の章の最後に言及した、「信頼の基点」すなわち「トラストアンカー」（図中では信頼点Trust Point）です。これは、証明書を利用するソフトウェア、例えばSSLで暗号化されたWebサイトを閲覧する場合はブラウザとなりますが、そこにCAの証明書がプリインストールされていることに相当します。例えば、MicrosoftのEdgeの場合、
右上の”…”をクリック＞設定で、
左側の「プライバシー、検索、サービス」をクリック＞証明書の管理
で、表示される画面の「信頼されたルート証明機関」タブを開くと、以下のようにプリインストールされたCA証明書のリストが表示されます。

例えば、図中でハイライトされた”Amazon Root CA 1”をダブルクリック又は「表示」ボタンを押すと、詳細情報が確認できます。

証明書の所有者は、証明書を提示する際に、同時にその証明書を直接発行したCA（前の図のCA2）の証明書も提示します。証明書の検証者は、最初に所有者の証明書のデジタル署名を、CA2の証明書に含まれる公開鍵で検証します。その次に、CA2の証明書のデジタル署名を、自分の証明書利用ソフトウェア（ブラウザ等）にプリインストールされて「信頼済み」になっている、CA1の証明書の公開鍵で検証することにより、最終的に所有者の証明書を検証することができます。

それでは何故、このようにCAは階層構造を取る必要があるのか？と言う疑問が生じると思います。それに対しては、以下のような理由が考えられます。

1. ルートCAをネットワークから切り離してセキュリティを高める
   言うまでもなく、中央集権型のPKIにおいては、CAのセキュリティが非常に重要になります。万が一にでも、CAのセキュリティが破られて、不正に証明書が発行されるような事態は防がなければなりません。更に、最上位のCAは「ルートCA」と呼ばれ、自分の秘密鍵で自身の公開鍵を署名したCA証明書を持ちます。トラストアンカーとしてブラウザにプリインストールされるようなCAが不正に侵害されるのは致命的です。ルートCAは、下位のCAの証明書を発行するだけですので、普段はネットワークから切り離して、不正侵入されるリスクを最小限に留めることができます。これが、通常2階層以上の構造にする一つ目の理由です。

2. 証明書の用途は複数（多数）あり、CAは用途別に構築・運営する必要がある
   一般的に、証明書の用途には、個人向けにはクライアント認証（証明書を身分証的に提示する）や電子メールの保護（メールの暗号化やデジタル署名）等、組織向けにはWebサイト認証（SSLサーバ証明書）等があります。CAは、発行する証明書の用途を証明書ポリシー（Certificate Policy。以下CP）として、更にどのようにCAを運営・運用するかを、認証局運用規定（Certification Practices Statement。以下CPS）として定め、それに沿って運用することが求められます。また、負荷分散や法規制の管轄地域の観点、かつ後述する本人の身元確認や組織の実在性確認のレベルに応じて、CAを分ける必要があります。そうすると、いちいち個別のCAを証明書利用ソフトにプリインストールして維持管理するのは大変なので、CAを階層構造にして、ルートCA等のより上位のCAをトラストアンカーとすることで、管理負荷を軽減すると言う側面もあるのかなと思います。

トラストアンカーの秘密

それでは、頼んでもいないのに（笑）、誰がブラウザにCA証明書を（勝手に）プリインストールしてくれているのでしょうか？実は、これは非常に重要な話なのに、意外と皆さんご存知ないのではないでしょうか？すなわち、デジタルトラストの根幹を成すとも言える「トラストアンカー」を、誰がどのような基準で選定・審査して、ブラウザ等の証明書利用ソフトウェアにインストールしているのか？と言う話です。

実は、CA事業者（DigiCert、GlobalSign、Let's Encrypt等）やブラウザ開発者（Apple、Google、Microsoft）等の証明書利用ソフトウェアの開発者から成る、CA/Browser Forumと言う業界団体があります。商用のCA事業者からすると、自社が発行する証明書の「受容度」が証明書の売れ行きを左右するでしょうし、ブラウザ等の証明書利用アプリケーション開発者にしても、最初から信頼済みになっているCAが多いほど受け入れ可能な証明書も多く、利用者の利便性も上がるでしょう。一方で、セキュリティレベルの低いCAが乱立しては困ると言う双方の利害が一致するため、CA/Browser Forumのような業界団体を設立し、CAの監査基準に関する議論や合意形成を行っているものと思われます。

具体的には、AICPA（米国公認会計士協会）とカナダ勅許会計士協会が定めた、WebTrust for CAと言う監査基準に準拠する必要があります。ちなみに、サービス事業者の内部統制でSOC1/2に言及しましたが、WebTrustはSOC3と呼ばれる「兄弟」みたいなものです。

PKIが担保するセキュリティの世界観において、CAのセキュリティは一番重要です。特に、ブラウザに信頼済みとされたCAの秘密鍵が悪意の第三者に漏洩したとすると、それに連なる下位CAを勝手に作られ、不正な証明書が発行され放題になってしまいます。よって、特にこのCAの秘密鍵管理に関する監査基準が非常に重要となっており、以下のような厳格な基準（ごく一部）が定められています。

項番	大項目	基準	詳細
3.4	物理環境セキュリティ	共通	CAの施設や設備への物理アクセスは、（中略）複数の人物（少なくとも二名）による相互牽制の下で行われる
3.4.5	物理環境セキュリティ	CA設備の物理セキュリティ	CP/CPSで開示されるような全てのCA運用業務（例：鍵生成やCA証明書の発行）における、電磁波の漏洩を防ぐために、物理的な障壁（例：ファラデーケージ）を設置すること
4.1.1	CA鍵生成	一般的な事項	CA鍵の生成は、FIPS 140-2等の要件を満たす暗号モジュール内で行われなければならない（後略）

私は20年以上前に、WebTrust for CAに準拠した電子署名法の認定認証局を作ろうとして上記の基準を詳細に調査したことがあります。しかし、余りに設備投資や運用コスト（人件費）が膨大になりそうだったので断念しました。そもそも、WebTrust for CAと電子署名法の認定要件の違いもあるでしょうし、当時とは基準そのものも変化していると思うので、現在でもその状況が当てはまるとは言えませんが、少なくともSSLのWebサーバ証明書に関しては、無償のLet’s Encryptも出て来てしまったので、商用CAはビジネス的に大変厳しい状況にあると言えるでしょう。

ブラウザやメーラーのように、不特定多数のWebサイトのサーバ証明書を検証したり、メールのデジタル署名を検証する必要がある場合には、上記のように証明書利用ソフトウェアの開発者が、事前に一定の監査基準を満たした（ルート）CA証明書を信頼済みとしてプリインストールしてくれた方が、一般の利用者的には便利です。しかし、技術者的には上記のような深い世界があることを理解しておかないと、痛い目を見ることもあるでしょう。一番分かり易いのは、多要素認証（Multi Factor Authentication。以下MFA）を実現する手段として、WebサイトのSSLクライアント認証を実装するときです。昔はApacheとOpenSSLの組み合わせが多かったのですが、この辺の仕組みを正しく理解しないまま実装した結果、幅広い商用CAから発行されたクライアント証明書を受け入れる設定のままになっていて、認証を強化した意味がなかったと言う悲しい状況を何度か見掛けたことがあります。システム開発現場のテストでは、正しいクライアント証明書を持っているケースと、持っていないケースのみを確認してリリースを迎えようとしていましたが、脆弱性診断を受けて上記の不具合を指摘されて、危うく難を逃れたケースもありました。PKIや証明書を利用するエンジニアは、「トラストする」ことの意味を、改めて良く理解する必要があると言えるでしょう。

トラストアンカーの悪用

ここ数年、「常時SSL（HTTPS）化」運動と言うのがあり、今や世界中のWebサイト通信の9割近くがHTTPSになっているそうです。通信が暗号化されるため、一般利用者のプライバシーも保護され、良いことばかりように思えますが、実は企業のセキュリティ管理者や、特定の国家の指導者たちにとっては、頭の痛い問題です。

例えば、最近のマルウェアの殆どは、Webサイトからのダウンロードによって配布されます。昔は、メールへの添付ファイルそのものがマルウェアだったりしたのですが、最近ではメール本文に載ったURLをクリックしたり、添付ファイルを開くと実行されるスクリプトが特定のURLにアクセスすることでダウンロードされるマルウェアが殆どです。従来の境界型防御モデルでは、社内のPCからインターネットに接続するゲートウェイ（プロキシ等）で、トラフィックを検査しウィルスやマルウェアの類いをブロックしていました。しかし、これだけHTTPSが普及していると、トラフィックが暗号化されているため、その検査が出来ないと言うのが一つ目の大きな問題です。

二つ目の問題は、情報漏洩の問題です。メールであれば、上司が部下の送信メールを承認又は事後監査するような仕組みを導入している会社もあると思いますが、Webサイトへの通信は即時性が求められるため、少なくとも承認は難しい。その上、HTTPSで暗号化されてしまっては、事後の監査も出来ないと言うことになります。更に、権威主義国家にとっては、掲示板やSNSで反政府運動が起こっていても、HTTPSで通信が暗号化されており、検閲出来ないのは死活問題となります。

そこで考え出されたのが、いわゆる中間者攻撃（Man In The Middle。略してMITMと呼ばれることも）的にプロキシが間に入って、SSLを復号してマルウェア検査や監査を行う方式です。

この場合、Webサイトへの通信の都度、プライベートCA（一般に公開されている＝パブリックCAと対比して、このように呼ばれます。セキュリティ界隈では「オレオレCA」とも）に、当該Webサイトの証明書を即時発行してもらい、プロキシがSSL通信を終端して、その間の通信のマルウェア検査や内容の監査を行います。即時発行で性能が求められるため、プライベートCAはSSLを終端するプロキシ等の機器に内蔵される場合が殆どです。

しかし、上記の図にもあるように、ここでトラストアンカーが問題になります。すなわち、企業内のプライベートなCAなので、社員等のブラウザにCA証明書がプリインストールされて「信頼済み」となっている訳ではありません。この状態でSSL暗号化されたWebサイトにアクセスすると、以下のような警告画面が表示されます。

この警告画面を出さないようにする方法は以下の通りです。利用者個人レベルでは、先ほど示したブラウザの証明書管理画面で、中央左の「インポート」ボタンを押すと、「証明書のインポートウィザード」が立ち上がります。

ここから、「次へ」ボタンを押すと、以下のようにインポートする証明書ファイルの指定画面が表示されるので、

当該プライベートCAのCA証明書ファイルを指定して、指示に従って進んで行くと、アクセス先のWebサイトが正しく表示されるようになります。

しかし、これを社員の一人ひとりにやってもらうのは大変なことです。普段、ITに関するサポート業務に携わってる方なら容易に想像できるでしょう。そこで、一般的には組織でプライベートCAの証明書を一括配布して、個人の証明書ストア（上述の画面で管理）に「強制的に信頼させる」ようなことが行われます。殆どの一般的な企業のOA基盤は、Windowsベースで構築されているでしょうから、この目的でActive Directory（以下AD）のグループポリシーが活用されます。いま手許に、自由に触れるADがないので、その手順を説明したMicrosoft社の記事へのリンクをここに示します。

さて、ここまで読んで、皆さんはどう思いますか？企業のセキュリティを守るために、暗号化通信の中のマルウェアを検査するのは理解できるとして、社員のプライバシーにも関わり兼ねない通信の内容を復号・監査するのは、やり過ぎではないかと感じた方もいるのではないでしょうか。実は、上記のようなSSL復号の仕組みを検討し始めた頃に、同様の議論が行われた組織をいくつか知っています。私は法律の専門家ではないので、正確には弁護士等の専門家に確認して頂きたいのですが、企業のOA基盤等のインターネット接続環境は、飽くまで企業としての業務目的で供されるものであると言うのが基本感のようです。勿論、社員のプライベートな通信が行われ得ることを想定して、過度に社員のプライバシーを脅かすことのないように配慮する義務があることは言うまでもありません。

一方で、前述したように、特定の国家においては、国民の通信を傍受・盗聴するために、トラストアンカーの仕組みが悪用されていると言っても過言ではありません。例えば、中央アジアのある国では、政府自らが「オレオレCA」を構築し、そのルートCA証明書を国内のインターネットサービス事業者（ISP）の顧客にインストールする必要があると通知したそうです⁷。また、オランダの商用CAであるDigiNotarが何者かに不正侵入され、偽のSSLサーバ証明書が多数発行されたと言う事件もありました⁸。事件発生前にDigiNotarが発行する証明書の有効性確認トラフィックの殆どがオランダ国内からだったのに対し、事件発生後は中東の某国からのトラフィックが激増したそうです。それにより、この事件の背後には国民の通信を盗聴しようとする某国政府が居るのではないかと疑われています。これらの事件に対しては、GoogleやApple等のブラウザ開発者による「信頼されたルート証明機関」のブラックリスト運用の強化や、Certificate Transparency（証明書の透明性）と呼ばれる、CAの証明書発行記録の公開等の対策が取られて来ています。自動車や工場の設備、ロボット等、今後ますます多くのモノが接続されるインターネットにおいて、そのセキュリティの根幹を成すトラストアンカーへの攻撃や脅威は増すばかりです。PKIに限らず、ルートDNSサーバをトラストアンカーとするドメイン名の名前解決システムにも同様の構造があると言えます。トラストアンカーの健全性を強固なものとするために、今後も不断の努力が必要となります。

IDトラストの保証レベル

これまでは主にPKIを前提とした議論を展開して来ましたが、ここで全てのエンジニアに共通の話題である「IDトラスト」、すなわち認証（Authentication）の話をしたいと思います。

認証については、古くて新しい問題と言うか、相手の顔の見えないインターネット上でビジネスを展開する上で非常に重要な課題・技術であるにも関わらず、昔は綺麗に整理された標準やガイドラインが無くて苦労したものです。そこに登場したのが、2006年に発行された米国立標準技術研究所（NIST）のSP800-63、通称「電子認証ガイドライン」です。初めてこの文書を読んだ時の衝撃は今でも忘れられません。ここまでエレガントに電子認証にまつわる課題を分析して、その対策を整理した文書は見たことがありませんでした。個人的に一番刺さったのは、古典的なIDとパスワードによる認証と、PKIによる暗号学的な認証、更には「あなたの母親の旧姓は？」と言うような所謂「クイズ認証」、当時インターネットバンキングで流行（？）していた「乱数表」による認証までをも、クロードEシャノンの情報理論における「エントロピー」を用いて、横並びで強度比較できる枠組みを提供したことです。最新版のNIST SP800-63からは、エントロピーに関する考察は消えているようですので、興味のある方は是非一度初版（エントロピーに関する考察は、P.49からの付録A）をご一読頂けると良いかと思います。

さて、直近の正式版である、第3版のNIST SP800-63-3によると、デジタルなID（一旦、ここでは「身分証」と解釈して下さい）の申請から取得、利用までの流れが、以下のように整理されています。

元々の図は英語ですし、今までの話の文脈から敢えて日本語に意訳している部分もありますので、くれぐれもご注意下さい。主なポイントは、上記のIDを「証明書」と読み替えると、左側の身元確認と中央の当人認証はPKIにおける証明書の申請とSSLクライアント認証のことですし、右側の認証連携と言うのは、最近のGoogle等の他のインターネットサービスによる認証を利用する「フェデレーション」のことを意図していると言う点です。しかし、原文を読むと、IDの部分には認証器（Authenticator）や資格情報（Credential）と言う言葉も使われています。皆さんも、1分毎に異なる何桁かの数字を表示するワンタイムパスワード（OTP）トークンと言う機器やソフトウェアを見掛けたことがあると思いますが、その辺も強く意識しています。

NIST SP800-63-3の最大のポイントは、上記の「身元確認」「当人認証」「認証連携」の確からしさの度合いによって、それぞれ「保証レベル」を定義したことです。それぞれ順番に、Identity Assurance Level (IAL)、Authenticator Assurance Level (AAL)、Federation Assurance Level (FAL)と呼ばれています。まさに現在、第4版のドラフトが公開されており、今後改訂される予定もありそうですが、それを踏まえて解説してみます。詳細は、NRIセキュアによる良い解説記事がありますので、そちらをご参照下さい。

まず、身元確認については、以下のようになります。

身元確認の保証レベル（IAL）の概要

保証レベル	IALの要件
IAL1	現実世界のID（免許証やパスポート等）と紐付ける必要はない
	身元確認のプロセスで提示された属性情報は自己申告
	認証の依拠者（RP）に提示される属性情報も同様で、自己申告として扱われるべき
IAL2	IDの申請者が現実世界に存在すると信じるに足る証拠の提示が必要
	申請者がその証拠に適切に紐付けられるか検証する
	リモート又は対面での身元確認が必要
	検証された属性と仮名のIDと共に、属性情報をRPに提示可能
IAL3	対面での身元確認が必要
	権限のある良く訓練されたCSPの代表者による属性の確認が必要
	（IAL2と同様に）検証された属性と仮名のIDと共に、属性情報をRPに提示可能

まず、IAL1については、無償のWebメール等のインターネットサービス利用時のアカウント登録を思い起こして頂ければ良いと思います。また、日本と米国では国土の広さや商習慣、法制度の違いもありますので、正確ではないのですが、ざっくりイメージを言うと、IAL2はクレジットカード加入時の手続き（厳密には年収確認等も入るので同じではありませんが）、IAL3はマイナンバーカード取得時の手続きだと思って頂けると、そこまで大きく違ってないのかなと思います。第4版での改訂の方向性としては、第3版のIAL1をIAL0に「格下げ」した上で、コロナ禍を経てデジタルIDも普及したことから、（後述のAALやFALの）一定以上の保証レベルを満たす他のデジタルIDを既に保有している場合は、上記のIAL2やIAL3における「身元確認」と同等の扱いが出来ると言う話もあるようです。

次に、当人認証についてです。こちらも、かなり詳細に技術的な基準が定められているのですが、紙面の関係上、概要レベルの説明に留めます。

当人認証の保証レベル（AAL）の概要

保証レベル	AALの要件
AAL1	サービス請求者が、正式な加入者の口座に紐付く認証器をコントロールしていると言う一定の保証が必要
	幅広く利用可能な認証技術を利用して、単要素または多要素による認証が必要
	認証の成功には、セキュアな認証プロトコルを通じて、請求者が認証器の保有とコントロールを証明する必要がある
AAL2	サービス請求者が、正式な加入者の口座に紐付く認証器をコントロールしていると言う高度な保証が必要
	セキュアな認証プロトコルを通じて、二つの異なる認証器の保有とコントロールの証明が求められる
	AAL2以上では、承認済みの暗号技術の使用が求められる
AAL3	サービス請求者が、正式な加入者の口座に紐付く認証器をコントロールしていると言う非常に高度な保証が必要
	AAL3における認証は、暗号プロトコルを通じた、暗号鍵の保有証明に基づく
	AAL3の認証は、ハードウェアベースでフィッシング耐性のある認証器を用いなければならない。同じ認証器が両方の要件を満たしても良い
	AAL3の認証では、セキュアな認証プロトコルを通じて、二つの異なる認証器の保有とコントロールの証明が求められる
	承認済みの暗号技術の使用が求められる

まず、AAL1は古典的なIDとパスワードによる認証を排除していません。更にAAL2は、二要素認証を求めていますが、例えば携帯電話のSMS（ショートメール）にOTPを送信して入力させるタイプの認証も許容されているように読めます。そしてAAL3では、「ハードウェアベースの認証器」とありますので、前述したようなOTPトークンが許容されているようにも読めますが、「フィッシング耐性のある」と言う条件があるため、AAL3は満たせないことになります。現在検討中の第4版では、AAL2でもフィッシング耐性が求められる可能性や、複数のデバイスで秘密鍵が同期されるパスキーの扱いに注意する必要がありそうです。

最後に、認証連携についてです。

認証連携の保証レベル（FAL）の概要

保証レベル	FALの要件
FAL1	ベアラアサーションを許可
	アサーションは承認された暗号方式によって署名される
FAL2	RPだけが復号出来るように、承認された暗号方式によってアサーションが暗号化される
	アサーションは承認された暗号方式によって署名される
FAL3	正当な加入者だけがアサーションそのものに加えて、アサーション内で参照される暗号鍵を保有することの証明の提示を求められる
	アサーションは承認された暗号方式によって署名される
	RPだけが復号出来るように、承認された暗号方式によってアサーションが暗号化される

ベアラアサーションとは、前述のデジタルID認証フロー図の「⑦認証結果の連携」で渡される、サービス請求者すなわち正当な加入者のIDや、検証者及びRPのID等を含むデータセットのことです。更に、全ての保証レベルに共通して、検証者によるデジタル署名が必要となります。更に、FAL2以上では、RP（認証の依拠者）だけが復号出来るように、アサーションの暗号化が求められます。更に、FAL3では、サービス請求者が当人認証時に用いた秘密鍵を保有していることの証明が求められます。現在検討中の第4版では、前述のCSPからRPに提供される属性情報等の事前合意を取っておくことや、ID取得時のIALや当人認証時のAALをアサーションに含めること等が要件として追加される可能性があるようです。

ここまで見て来ると、高い保証レベルを実現するためには、公開鍵暗号技術を採用せざるを得ないことが分かります。一般的にインターネット上の認証は、本人しか知り得ない秘密（情報）を持っていることを、相手が検証することによって行われます。秘密を素直に提示してしまうのがIDとパスワードによる認証やOTPによる認証です。これらはフィッシングサイトに容易に詐取され得る、すなわち「フィッシング耐性」が無い認証方式ですので、AAL3の要件を満たしません。「フィッシング耐性」のある認証方式で一番普及しているのが、やはりPKIベースの証明書による認証と言うことになります。上記の要件概要には明記されていませんが、AAL3では耐タンパ性（内部情報を不正に読み取られる・改竄されることに対する耐性）のあるICカード等のハードウェアに秘密鍵を格納するクライアント証明書認証（まさに、マイナンバーカードが一例）が最も一般的な実装方式でしょう。最近では、FIDO2に準拠したUSBタイプのセキュリティキーが出て来ており、比較的簡単に実装できます。

それでは、上記のように認証に関わる各プロセスにおいて、「保証レベル」を定義する意味とは何でしょうか？それは、この記事のテーマである「トラスト」に大きく関係があります。冒頭に引用したように、「トラスト」とは「事実の確認をしない状態で、相手先が期待したとおりに振る舞うと信じる度合い」ですから、保証レベルが高い程、インターネットの向こう側に居る顔の見えない相手が主張する本人である可能性は高いと言うことになります。サービス提供者側から見ると、例えば成りすましによる金銭被害の危険性が高い程、保証レベルを高くする必要がありますし、逆にサービス利用者側から見ると、例えば医療等の機微な個人情報を取り扱うようなサービスでは、高い保証レベルのサービスでなければ利用したくないと思うのではないでしょうか。

ただし、一点注意すべき点があります。それは時間軸の概念です。つまり、それぞれの保証レベルで定義された状況は、恒久的なものではないと言うことです。インターネット上で出来ることが増えれば増えるほど、攻撃者も他者に成りすますことで得られるメリットが大きくなり、身元確認や当人認証等の「抜け穴」を鵜の目鷹の目で見つけ出そうとしてきます。各事業者の置かれたビジネス上、技術上の状況を踏まえつつ、常にリスク評価しながら、改善を図って行くことが重要だと思います。

ご参考までに、NIST SP800-63-3では、具体的にどの保証レベルを選ぶべきかの検討に利用できるフローチャートが提示されています。原文（英語）のまま引用するに留めますが、興味のある方は読み解いてみて下さい。

例えば、IALの場合は、サービスを提供する上で個人情報を取得する必要があるか、またサービス提供者と利用者のいずれかにおいて、何か問題があった場合に、信頼の失墜、金銭的被害、公共の利益に反する、機密情報の流出、個人の安全、犯罪行為の、いずれかに繋がるリスクが高い場合は、IAL3を採用しなさいと言うことになります。

AALの場合も、同様のリスクが高い場合は、AAL3を採用しなさいと言うことになります。

FALの場合は、そもそもサービス提供者として認証連携を採用する前提で、同様のリスクが高い場合は、FAL3を採用しなさいと言うことになります。

データトラストの種類

前述したように、「データトラスト」とは、そのデータを生成した主体（①自然人、②法人、③機器）とデータの紐付けを確立し、かつ④ある時点で確実にそのデータが存在し現時点まで書き換えられていないことを担保することで実現できます。本来であれば、データの中身の真実性や信憑性も、データトラストの重要な要素と言えるかも知れませんが、某国の大統領選挙でフェイクニュースが飛び交ったり、某県の県知事選挙でSNSが濫用される状況を見るに、現実空間でさえ情報の真実性や信憑性を担保するのが難しいことを痛感します。したがって、この記事では情報の中身の真実性や信憑性に関しては議論の対象外とし、以下では上記の①から④の現状を見て行きたいと思います。

先ほどの「IDトラスト」では、米国のNIST SP800-63-3をご紹介させて頂きましたが、「データトラスト」の分野では、制度設計と社会実装ともに、欧州（EU）が進んでいる印象です。欧州では、通称eIDAS⁹と呼ばれる欧州域内におけるデジタルIDやデータトラストに関わるトラストサービスを規定した規則が2014年に発効しました。それを参考に、日本におけるトラストサービスの制度整備状況を示した図（令和6年時点）が総務省から出ています。

①の自然人と電子文書の紐付けを明確化するのが電子署名で、日本では2001年に電子署名法が成立しています。法律には明記されていませんが、別途定められた基準で実質的にPKIを用いることが想定されています。つまり、電子（デジタル）署名を生成する以前に、本人の認証が重要なので、本人の身元確認を厳密に行った上で、署名用の電子証明書が発行されます。当該基準に従っていることの監査を受けて合格したCAは「認定認証業務」と呼ばれます。前述したように、電子署名法の認定認証業務の認定基準は、WebTrust for CAをベースとしています。電子署名法の施行から20年以上経過したこともあり、電子署名法認定基準のモダナイズ検討会と言うのも開催されているようです。

②の法人と電子文書の紐付けを明確化するのが欧州で先行しているeシールで、やっと日本でもこの4月に総務省から「eシールに係る指針（第２版）」が示され、現在認定制度の創設に向けた技術上、運用上の基準を整理しているようです。法人が発行する電子文書としては、請求書や見積書、領収書と言ったものが想定されます。以前から、このニーズはあったと思いますが、コロナ禍で経理担当者が出社を余儀なくされる状況となり、一気にこの問題がクローズアップされたと思います。また、電子インボイス制度も始まり、単なる請求書のデジタル化だけでなく、発行元の真正性や不正に書き換えられていないことの証明は、今まで以上に重要となるでしょう。

③の各種センサー等の機器が生成・発出したデータの真正性証明ですが、総務省の図では「モノの正当性の認証」に該当します。これに関しては、現時点で日欧ともに公的な制度はありません。しかし、今後ますます多くのモノがインターネットに繋がるIoT時代において、このニーズが高まることは言うまでもありません。一つのアイディアとしては、機器本体や隣接する通信機器にTPM（Trusted Platform Module）のような、秘密鍵をセキュアに格納できるチップを搭載し、その機器が発出するデータにデジタル署名を付すことです。この場合、その機器を保有する個人や法人の実在性確認や、その機器が乗っ取られて不正なデータを生成することがないようなセキュリティ監査を受けた上で、TPMチップ内の秘密鍵に対応する公開鍵証明書を発行するようなPKIが必要となります。実際、欧州データスペース（企業間のデータ連携基盤）の技術標準開発を行う、IDSA（International Data Spaces Association）のホワイトペーパーに、それに近いアイディアが詳述されています。その中の図を一部引用します。

上記の図で、IDS Connector（コネクタ）とあるのが、センサー等のIoT機器に搭載されたデータ送受信用のソフトウェアだと思って下さい。上のDevice CAから証明書を発行してもらって、受信者側は自身の属性情報を含むアクセストークン（DAT）を入手して送信者側に送付し、送信者側はデータの送信可否を判断します。この際、送信者側は送信データにデジタル署名を付すことも出来るはずですが、この図ではそこまで表現されていません。

上記の図の上に、紫色の箱でCompany Description + Signaturesとありますが、ここに事前のセキュリティ監査のレベルが含まれます。また、下の桃色の箱でMeasurements(incl. Nonce) signed by Connectorとありますが、これはコネクタの起動時にソフトウェアスタック（上の黄色の箱のSoftware Manifests + Signatures）が不正に改竄されていないことの整合性チェックが行われて、その結果にコネクタが署名します。これを双方に送り合うことで、相手のセキュリティを信頼するのです。
ご興味のある方は是非、IDSの参照アーキテクチャモデルの原文に当たって見て下さい。

④の「ある時点で確実にそのデータが存在し現時点まで不正に書き換えられていないこと」は、まさに総務省の図の「タイムスタンプ」に該当します。こちらは既に、総務省告示の認定制度があり、例えば「電子帳簿保存法」では、帳簿や書類等の国税関係書類を電子データで保存する際には、認定事業者によるタイムスタンプを付すことが求められています。現在主流で認定の対象となっているタイムスタンプの方式もPKIベースです。非常にざっくり説明すると、電子（デジタル）署名は文書（データ）の生成主体と文書を紐付けるのに対して、タイムスタンプは時刻と文書を紐付けると理解すると良いでしょう。ただし、証明書には有効期限があるため（公開鍵暗号でも、長い時間と大量の計算機資源を費やせば解読されるリスクがあり、それを低減するために数か月から数年程度の有効期限を設定）、長期間保存が求められる文書の場合は、証明書の有効期限に応じてタイムスタンプも更新して行く必要があります。

実は、タイムスタンプには別の方式もあり、2000年代当初は「スーパーハッシュ方式」と呼ばれていたように記憶しています。PKIベースの方式は「シンプル・プロトコル」、別方式は「リンキング・プロトコル」とも呼ばれました。今ではPKIベースの方式が主流なので、インターネットを検索しても後者の情報がなかなか出てこないのですが、2003年3月に発行されたタイムスタンプサービス調査報告書と言うのを見つけました。この資料から引用して簡単に説明します。

TSAは、Time Stamp Authorityの略で、タイムスタンプを発行する機関となります。サービス利用者は、タイムスタンプが欲しい文書（データ）のハッシュ値を取り、TSAに送付します。TSAは、一定期間の間に受領した全てのタイムスタンプについて、上記の図の「トーナメント表」のように、2つのハッシュ値の組み合わせから更にハッシュ値を計算して行って、最終的に当該期間のトーナメント優勝者に相当するハッシュ値（$RH_i$）を算出します。最後に、一つ前の期間のスーパーハッシュ値（$SRH_{i-1}$）との組み合わせから、当該期間のスーパーハッシュ値（$SRH_i$）を計算し、それを新聞紙上等で公告します。タイムスタンプの申請者（$H1$）に対しては、スーパーハッシュ値（$SRH_i$）と時刻、途中経路のハッシュ値全て（$X1$、$Y1$、$RH_i$）が、タイムスタンプ情報として返されます。もし、タイムスタンプ対象となる文書のいずれかが書き換えられると、同様の計算手順で計算されたスーパーハッシュ値が新聞紙上に公告された値と違って来るので、改竄が検知出来ることになります。前述したように、PKIベースの方式は証明書の有効期限があるので、タイムスタンプを更新して行く必要があるのですが、スーパーハッシュ方式はその必要がなく、長期保存に向いていると言われていました。更に、前述したように、PKIのセキュリティはCAのセキュリティに大きく依存します。逆に言うと、CAのセキュリティが侵害されると、PKI全体の信頼性が損なわれてしまいます。しかし、スーパーハッシュ方式は、万が一TSAが侵害されても、既に新聞等で過去のスーパーハッシュ値が公告されているため、侵害以前の文書の実在性や非改竄性は同様の計算手順により第三者が検証出来ます。そのような優れた特性を持つ「スーパーハッシュ方式」ですが、今ではその言葉すら目にしなくなったのは寂しい限りです。それでも、 10年以上前に、ある新しいセキュリティ技術が登場して来たときに、私はまさにこの「スーパーハッシュ方式」を思い起こしました。 今でも呼ばれ方やユースケースを変えながら、期待の高い技術ですが、果たしてそれは何だと思いますか？（後述します）

ところで、生成AIの登場で、新しいタイプの「データトラスト」が注目を浴びつつあります。個人的には、生成AIが偽造しているかも知れない、フェイクニュースや偽画像、偽動画等の「偽物」を見破る技術をいくら開発しても、それを見聞きした人間が先に信じてしまっては元も子もないと思うのです。真偽の程は置いておいて、前述した某国の大統領選や某県の県知事選のSNSを巡る騒動ですね。それに対して、デジタルコンテンツの出所・来歴を証明することで、せめて「本物」だけは明確に分かるようにしようとする動きがあります。グローバルでは、AdobeやMicrosoft他の、デジタルコンテンツの生成に関わる企業がC2PA（Coalition for Content Provenance and Authenticity）と言う標準化団体を結成し、仕様検討を進めているようです。ご想像のように、これもPKIベースの技術仕様となります。

詳細は割愛しますが、例えばデジタル写真であれば、デジタルデータそのものに加え、撮影日時、撮影場所、使用カメラ、加工に利用したツール、加工内容等の来歴情報にデジタル署名が付されて添付され、別途検証ツール（開発者用にc2patoolと言うのがあるようです）で検証することが出来ます。もし次回、記事を執筆する機会があれば、この辺を紐解いてみたいと思います。日本にも、オリジネータープロファイル（OP）と言う、同様の取り組みがあるようですが、ぱっと見、C2PAと目指すところの違いが良く分かりませんでした。もしご存知の方がいらっしゃれば教えて頂けると幸いです。

ブロックチェーンのトラスト（分散型PKI？！）

それでは、「みんな大好きブロックチェーン」の話をしたいと思います（笑）。ブロックチェーンには、今まで説明して来た、電子署名、タイムスタンプの技術要素が含まれています。ブロックチェーンの解説記事は沢山ありますので、改めてここで詳細に説明することは避けますが、ソフトバンクさんの解説記事が分かり易くまとまってお勧めです。

ブロックチェーンは良く「分散管理台帳」とも呼ばれますが、これが一つの特徴を良く捉えていると思います。つまり、ブロックチェーンの参加者（ノード）がビットコイン等の仮想通貨（トークン）の取引（処理）をした記録を、みんなで共有して、その正当性を担保しようとするものです。参加者はそれぞれ秘密鍵と公開鍵を持ち、一対一（Peer to Peer：P2P）での取引の記録に秘密鍵で署名します。一定時間内の取引の記録を集めたものは「ブロック」と呼ばれますが、過去に遡って取引の履歴の正当性を担保するために、各ブロックには直前のブロックのハッシュ値が含まれます。もし過去の取引記録が改竄されたら、それ以降のブロックのハッシュ値と不整合が発生するため、不正を検出できると言う訳です。図にすると分かり易いですが、ブロックとブロックが鎖のように繋がるので「ブロックチェーン」と言う訳です。あれ？これってどこかで見覚えありませんか？ 私は、初めてSatoshi Nakamotoのビットコイン論文を読んだときに、タイムスタンプの「スーパーハッシュ方式」に似ていると思いました。 現に、エストニアにGuardtimeと言う会社があり、彼らはビットコイン論文登場以前の2007年に創業していますが、当時からタイムスタンプ的なサービスを提供していたと記憶しています。今では、「KSI（Keyless Signature Infrastructure：鍵のない署名基盤）ブロックチェーン」と言う独自のプラットフォームを提供し、電子立国エストニアの一翼を担っています。

さて、みんなで共有・管理する「分散管理台帳」ですので、新しいブロックを作ってその前のブロックに連結する処理が一番重要で、その合意を取るための仕組みが「コンセンサスアルゴリズム」となります。ビットコインにおいては、ある難しい計算をみんなで競って、一番速く解いた人が取引記録を承認する権利を得て、報酬としてビットコインを貰えるプルーフ・オブ・ワーク（PoW）と呼ばれる仕組みです。一方で、イーサリアムにおいては仮想通貨の保有額と期間に応じて、ランダムに承認者が割り当てられて報酬が得られるプルーフ・オブ・ステーク（PoS）と呼ばれる仕組みです。ブロックチェーンの場合、取引相手が現実世界の中の誰かは全く気にしないと思います。つまり、相手が誰であろうと、正しく仮想通貨なりトークンの授受が出来れば良いと言う考え方¹⁰ではないでしょうか。その意味で、ブロックチェーンは「トラストレス」である、と言う説明もされたりしますが、それは少し違うと思っています。

結論から言うと、ビットコインやイーサリアム等の仮想通貨を保有しようとする人は、上記のようなブロックチェーンの仕組みで、自分の財産や取引の正当性が担保されることを「信頼＝トラスト」して、参加していると言えます。勿論、仮想通貨（暗号資産）取引をする全ての人が、ブロックチェーンの仕組みを正しく理解しているかと言うと、極めて疑問ですが（苦笑）。ただし、暗号資産取引の場合、大部分の人が取引所にウォレット（財布。秘密鍵を管理）を預けているので、ブロックチェーンの仕組みの理解以前に、殆ど盲目的に取引所のセキュリティを信頼していると言えるでしょう。自分でウォレットを持っている人は、ブロックチェーンの1ノードとして参加している、すなわちブロックチェーンの安全性の一端を担っていることになります。これまでのPKIに関する説明を理解していれば、一参加者としては自分の秘密鍵を守ること、すなわちウォレットのセキュリティが非常に重要であることは容易に想像がつくでしょう。

一方で、従来型のPKIとの大きな違いは、中央集権的な絶対君主とも言えるCAが存在しないことです。従来型PKIの場合、万が一にでもCAが侵害されると、PKI全体の信頼性が損なわれます。それに対して、ブロックチェーンの場合は、コンセンサスアルゴリズムによってその度合いは異なりますが、参加しているノードに、ブロックチェーン全体としての信頼性が分散されていると言えます。従来の中央集権型のPKI（階層型CAモデル）に対して、ブロックチェーンを「分散型のPKI」と呼ぶのは言い過ぎでしょうか。

ただし、ビットコイン等のPoWの場合は、全参加ノードの計算機資源の合計の51％以上を占めるノードが存在すれば（PoWの計算競争で勝利するため）、そのノードがブロックの承認を支配出来てしまうことになります。イーサリアム等のPoSの場合も、仮想通貨の保有額が多いほど支配権が強まりますが、自らの財産を毀損するような不正を働くインセンティブは無いだろう、と言うことになっています。また、ビットコインやイーサリアム等は誰でも参加できる「パブリック型」と呼ばれるのに対して、参加する際に何らかの身元確認や一定の条件を満たす必要があるブロックチェーンは「プライベート型」や「コンソーシアム型」と呼ばれます。これらのタイプには、バリデーター（検証者）と呼ばれる、ブロックを承認する特権ノードが存在しますが、それらのノードが中央集権型のCAに近い位置付けと言えるでしょう。つまり、トラストの観点から見ると、その基点（トラストアンカー）が一極集中するのが中央集権型のPKI（CA）モデル（又は特権ノードが一つのプライベート型ブロックチェーン）、複数に分散するのがコンソーシアム型やパブリック型のブロックチェーンと言えるのではないでしょうか。ただし、前述したように、ブラウザ等のPKI利用ソフトウェアにトラストアンカーとしてCAが登録されるためには、WebTrust for CAのような厳格なセキュリティ基準の第三者認証を取得する必要があります。ブロックチェーンや仮想通貨、暗号資産の信頼性を高め、より社会的な普及を目指すのであれば、中央集権型PKIの過去からの経験を有効活用して行くべきと考えます。

データ主権、自己主権型ID（SSI）、DID/VC

さて、やっと今回の本論に近付いて来ました。「どんだけ前振りが長いんだよ！」と突っ込みを受けそうですが、もう少しお付き合い下さい。

最近、「データ主権」と言う言葉を耳にする機会もあると思います。「ソブリン（主権）クラウド」のように、GAFAMにデータが流出・独占されることを危惧した欧州のGDPRを端緒として、「国家」が自身の法的枠組みの中で、データセンターやその中で扱われるデータを主体的に管理すると言う文脈で語られることが多いように思いますが、以降では「個人」「組織」を前提としたお話をさせて下さい。「個人」や「組織」の文脈の場合、特に「自己主権（Self-Sovereign）」と呼ばれることがあることを、申し添えておきます。

ランサムウェアが猛威を振るい、大量の個人情報漏洩の事件が後を絶ちません。また、ECサイトが改竄されて、クレジットカード決済用のスクリプトが書き換えられることによる、カード情報の盗難・漏洩事件も最近とみに増えている印象があります。それぞれ、ランサムウェア対策やWebサイトの脆弱性管理等、直接的な対策はあるものの、委託先やEC事業者頼みでは、消費者としては非常に不安なところです。「ちゃんと管理してくれないなら、これ以上自分の個人情報を預けたくない！」と言う感情が沸き起こるのも、自然なことではないでしょうか。そこで、「自分のデータの取り扱いは、自分で決めたい」と言うニーズで生まれて来たのが、「自己主権型ID（SSI）」と言う考え方です。

これを実現する方式はいくつか考えられます。例えば、最近のWebサイトでは、「Google認証」や「Facebook認証」のように、既に自分がアカウントを持っているSNS等の認証に依存して、アカウントの登録や利用時の認証を行ってくれるサイトが増えて来ました。「IDトラスト」の章で述べた「認証連携」の機能です。このQiita自身もそうですね。この際、認証元のサービスから「この情報を認証先に連携して良いか？」と細かく聞いて来てくれるので、利用者としてはそれに対応することで、ある程度自分の情報のコントロールが出来ていると安心できます。つまり、完全ではないにしても、これもSSIの理想に近付くためのアプローチと言えそうです。この概念を図示すると、以下のようになります。

この図は、ある程度実装をイメージしたような図になっていますが、SSIとは飽くまで「ユーザ自身がIDの提供者となり、自らの情報を管理・制御する思想」であり、実装までは規定していないと言う理解です。

一方で、最近SSIの実装形態として大きな注目を浴びているのが、DID/VCすなわち「分散型ID（Decentralized ID。以下DID）」と「検証可能クレデンシャル（Verifiable Credential。以下VC）」です。DID/VCをざっくり説明すると、以下のような図（NRIセキュアの記事より引用）になります。

この図の下にある、「ユーザ情報が信頼できる情報であることを担保するための情報を保管」と言うところが、この記事のテーマである「トラスト」に大きく関わって来ます。これを詳しく見て行く前に、DID/VCのユースケースを簡単に説明します。

上記の図は、旅行先でレンタカーを借りる場合と、病院で診察を受ける場合の二つのユースケースを一つの図の中で表現しています。ざっくり説明すると、ユーザの識別子と公開鍵の情報がDIDで、免許証や電子カルテに相当するものがVCだと思って下さい。つまり、DIDが従来の中央集権型PKIにおける公開鍵証明書に相当します。一方で、VCを「デジタル証明書」「証明書」と説明している記事もありますが、これまでの議論の流れで言うと「本人の資格や属性情報を証明するための第三者によるデジタル署名」の説明の方が正しいかも知れません。

DID/VCのトラスト

それでは、DID/VCの詳細とトラスト構造について見て行きたいと思います。DID/VCはW3Cによって標準化されていますので、詳細はW3Cのサイト（DID/VC）をご確認下さい。

まず、DIDは以下のようなフォーマットの単純な文字列です。

冒頭のスキーム（Scheme）は、DIDの話をしているので"did"で固定となりますが、二つ目のDIDメソッド（Method）がトラスト構造の仕組みを表し、三つ目がDIDメソッドに固有の識別子（DID Method-Specific Identifier）となります。実はこれだけではなくて、他にもDIDを構成する要素があります。それを表現したのが以下の図（W3CのDIDサイトから引用）です。

左上のDIDサブジェクト（subject）が、DIDを持つ主体で、人、組織、モノ等、何でも良いです。それを識別するのがDIDで、DIDメソッドに応じて適宜（名前）解決されてDIDドキュメント（document）を指し示します。つまり、DIDドキュメントがDIDの「中身」と言えます。W3のサイトにある、DIDドキュメントの例を引用します。

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

6行目の"id":で始まっている部分がDIDの識別子を表し、"authentication":以下のブロックが当該DIDの主体を認証するための公開鍵情報となります。そして、このDIDとDIDドキュメントを紐づけて管理する（DIDから名前解決してDIDドキュメントを指し示す）のが、上の図のVerifiable Data Registry（検証可能なデータレジストリ。以下VDR）となります。まさに、VDRの実現方式はDIDメソッドによって異なりますので、DID/VCのトラストの肝はDIDメソッドにあると言って過言ではありません。

「DID/VCと言えばブロックチェーン」と言う誤解があります。確かに、Microsoft社によるDID/VCの初期の実装では、ビットコイン上のレイヤ2オーバレイネットワークがVDRとして使われていましたが（DIDメソッドで言うと、did:ion）、最近では通常のドメイン名の名前解決とその参照先としてのWebサイトの仕組みを用いた、did:webと言うDIDメソッドを多く見掛けるようになりました。例えば、

did:web:example.com

と言うDIDのDIDドキュメントは、

https://example.com/.well-known/did.json

にアクセスすることで取得出来ると言う寸法です。DIDにドメイン名（FQDN）だけを含む場合は、/.well-known/did.jsonを見に行きますし、ユーザ名も含む場合、例えば

did:web:example.com:username

と言うDIDのDIDドキュメントは、

https://example.com/username/did.json

で取得できます。つまり、先ほどの/.well-known/の部分が、/username/に置き換わる訳です。

did:webは、ドメイン名とその配下のWebサイトを所有していれば、DIDドキュメントを登録・管理することが出来るので、そこに信頼の基点（トラストアンカー）を置くと言う思想でしょう。更に、SSLでアクセス（https://）する場合は、当該Webサイトが信頼済みのCAから発行されているサーバ証明書を持っていれば、信頼の度合いが高まります。とは言え、最近では無償でサーバ証明書を発行してくれるLet's Encryptのシェアが非常に大きくなっています。Let's Encryptの場合、ドメイン名を保有していることが機械的に確認されると、証明書が即時発行されるため、先ほど「IDトラスト」の章で説明した身元確認の保証レベル（IAL）が、ドメイン名の取得時の本人又は組織の身元確認と同等となります。いずれにせよ、トラストに関して言うと、DID/VCにしても、ブロックチェーンのような分散型のアーキテクチャではなく、ドメイン名の名前解決（DNS）のようなインターネット創設以来の中央集権型のアーキテクチャに、ある程度依存していることを認識しておく必要があるでしょう。

VCのトラストに関しては、結局Issuer（発行者）による秘密鍵でデジタル署名され、その信頼性は発行者のDIDに紐付く公開鍵で検証されるので、

上記のDIDのトラストの話に帰結します。しかし、VCやVP（Verifiable Presentation。VCを提示用のフォーマットに変換したもの。以下VP）に関しても、選択的開示やゼロ知識証明の応用と言った、非常に興味深い話題があるので、またの機会にご紹介したいと思います。

欧州の企業間データ連携基盤構想Gaia-Xと自動車業界版のCatena-X

SSIやDID/VCの登場以前から、欧州ではドイツのIndustrie 4.0戦略（産業製造機器をインターネットに接続し、サイバー空間に物理空間の写像を作って、製造業を高度化する試み）に端を発し、「データスペース」と言う企業間のデータ連携基盤を作ろうとする動きが進んでいました。その理論的支柱となっているのが、「データトラスト」の章で「モノが生成するデータの真正性」に関する説明で引用した、IDSA（International Data Spaces Association）です。IDSAは、ドイツのフラウンホーファー研究所が中心となって設立した、130社以上の企業・団体による連合体です。「データスペース」と言うと、GAFAMのように、欧州のどこかに構築されたクラウド基盤上のデータベースがあって、そこで中央集権的に複数企業のデータを管理するようなイメージを持たれるかも知れませんが、全く逆の発想となります。つまり、先ほど「データトラスト」の章で説明したように、データはそれぞれの所有者が保持した上で、データの利用条件を「契約」として送受信者間で取り交わした上で、データ交換を行おうとするものです。それを実現する中核となるソフトウェアが前述のIDSコネクタで、当初はIDSAにより開発され、オープンソースソフトウェア（OSS）として公開されました。

そして、IDSAのデータスペースを更にドイツを中心に欧州域内の国家レベルで推進して行こうとする動きがGaia-Xです。Gaia-Xは、企業間でデータを共有するニーズの高そうな業種・業界単位でデータスペースを構築して行くための共通基盤やルールを定めています。ここで、興味深い動きがありました。Gaia-XはIDSAのデータスペース構想、もっと言うとIDSコネクタからスタートしたはずなのですが、微妙に「分派」と言うか、違う動きを見せ始めたと言うことです。前述の「データトラスト」の章で説明したように、IDSコネクタベースの認証・認可の仕組みは、中央集権型のPKI（CA）モデルだったはずなのですが、Gaia-X発足後にSSIやDID/VCの概念や技術が登場して来たためか、Gaia-Xは分散型のDID/VCを「IDトラスト」のアーキテクチャとして採用しました。また、IDSコネクタはOSSで有名なEclipseファウンデーションの管理によるEDC（Eclipse Dataspace Components）コネクタに変わりました。IDSAは、データスペースの構築に必要な共通基盤に関しては、そこまで明確に規定していなかったので、Gaia-Xとして独自に設計・構築する必要があり、その中で思想の違いと言うか、時代の流れが反映されたとも言えるでしょう。IDSAは、データスペースの考え方や、コネクタ間でデータ利用条件の合意と送受信を行うDataspace（データスペース）プロトコルの普及と標準化に注力しつつあるように見えていて、その部分においてはGaia-Xも引き続きIDSAと足並みを揃えて行くと思われます。

さて、Gaia-Xの個別業界版として、いち早く立上りつつあるのが、自動車業界版のCatena-Xです。

Catena-Xの実装面での特徴を簡単に説明すると、まずEDCコネクタや今後Catena-Xで多用されるであろう共通のSDK（ソフトウェア開発キット）の開発と維持管理が、Catena-X独自のOSS開発コミュニティTractus-Xで行われている点と、更に「IDトラスト」の章のNIST SP800-63-3アーキテクチャ図で「身元確認」を担うCSPの機能を、Gaia-XのDigital Clearing House（GXDCH）に依存している点が挙げられます。また、Gaia-Xを踏襲して、Catena-X内の認証・認可は、SSIと言うか、DID/VCが使われるとのことです。ただし、後述するeIDAS 2.0によって、欧州域内の国民や企業にID管理ウォレット（EUDIW）の普及が義務付けられたばかりですので、Catena-XにおいてはひとまずマネージドIDウォレット（MIW）、すなわちCatena-Xの運営主体側（上記の図中のAuthentication DAPS → Cust. Wallet）で、利用者のDID（の秘密鍵）やVCの管理を請け負う形態を取るようです。暗号資産取引所にウォレットを預けているようなものですね。

Catena-Xの大きな普及ドライバとなり得るのが、欧州電池規則です。これは、欧州で電気自動車（EV）等の産業機器に搭載される一定以上の出力の畜電池を販売する事業者は、今後デジタルプロダクトパスポート（Digital Product Passport。以下DPP）の一種である、電池パスポートを発行することが求められると言う規則です。

電池パスポートは、原材料である希金属（リチウム、コバルト等）の採掘・精錬事業者や、部品製造者、更には流通後の充電・放電の情報や、リサイクル情報等、多岐に渡る企業からデータを収集し、それぞれのデータ利用に関する要件（競合他社にはデータを開示したくない等）を取り込んで実装する必要がありますが、それを実現するデータ連携基盤としてCatena-Xが有望視されています。必ずしもCatena-Xではなく、DID/VCの性質を利用すると実現出来そうなのですが、その場合は以下のようなイメージとなります（自分で言っておいて矛盾するようですが、図中の「○○証明書」とはVCのことです）。

つまり、電池のサプライチェーンやバリューチェーンに連なる事業者が、それぞれDIDを持ち、自分の担当部分に関するCO2の排出量や原材料の情報等をVCとして発行する。更に、外部の監査人が、それらの情報が適切に管理されているか？とか、人権侵害に繋がるような不当労働行為が行われていないか等を監査し、その監査表明をVCとして発行するようなイメージです。そして、「電池」自体も主体としてDIDを持ち、それらの多数のVCを集めてウォレットで管理し、必要に応じてそれぞれのデータ利用条件に合わせて提示（VP）すると言う考え方です。ただし、今のところCatena-Xにおいては、アセット管理シェル（AAS）と呼ばれる入れ子構造のデータモデル（XMLやJSONでシリアライズ可能）で、電池の部品や材料のデータを管理し、電池パスポートの総体を管理するようなアプリをCatena-X上で提供して、アプリの起動後に都度データの利用条件を確認しながら、部品や材料のデータを一対一でデータの提供者と消費者（＝アプリ利用者）の間で通信する（この時、EDCコネクタが利用される）ような考え方で実装されそうです。これを今後、当社では実際にCatena-Xに接続して、検証して行く予定です¹¹。

食品や衣類、プラスチック等のトレーサビリティ（追跡可能性）にも応用できるDPPは、今後脱炭素社会や循環型経済を目指して行く上で、非常に重要な技術になると考えています。

EDCコネクタ間のデータ送受信は、以下のようなイメージです。

Tractus-X上に公開されているEDCコネクタには、「契約」合意時のデジタル署名や、送信データそのものの真正性を担保するデジタル署名を付すような実装が未だ入っていないようです。MIWで、EDCコネクタ自身がDIDの公開鍵に対応する秘密鍵を持っていないのが大きな理由なのかも知れませんが、アーキテクチャ的には非常に良い線行ってると思うので、是非最後の「詰め」に相当するところを、頑張って欲しいものです。出来ればその実装に、当社も貢献したいと考えています。

中央集権型と分散型の狭間で

「データトラスト」の章で2014年に成立したeIDASについて簡単に触れました。これをeIDAS 1.0と呼ぶとすると、つい最近の2024年3月にeIDAS 2.0が成立しました。

詳細については、NRIセキュアによる良い解説記事がありますので、そちらをご覧頂きたいと思います。これは、欧州加盟国の市民に対して「欧州デジタルIDウォレット（EUDIW）」を提供することを義務付けるものです。他にも、「属性の電子証明」「電子台帳」「リモート署名」等、明確には書かれていませんが、DID/VCやブロックチェーンへの対応を強く伺わせています。

しかし、そうすると大きな疑問が生じます。既に普及しているeIDAS 1.0は従来型の中央集権型PKI（CA）モデルであり、分散型のDID/VCやブロックチェーンにも対応しようとするeIDAS 2.0との互換性や相互接続性をどうやって維持するのか？と言う問題です。また、前述したように、中央集権型のPKIを採用していたIDSAから、分散型のDID/VCにシフトしようとしているGaia-X及びCatena-Xにも同様の課題があると言えます。

そこで調べてみたところ、まさに中央集権型のPKIにおける公開鍵（X.509）証明書と、分散型のDID/VCを橋渡しする方式を図示している文書を見つけました。そこから図を引用しつつ、解説を加えたのが以下の図となります。

要するに、X.509証明書とDIDの両方で、同一の公開鍵暗号方式と公開鍵・秘密鍵のペアを用いると言うことです。図中の「eIDAS適格トラストサービス」とは、eIDASの世界における「トラストアンカー」と考えて頂ければ良いと思います。つまり、DIDの公開鍵に対して、eIDAS 1.0の認定認証局（CA）から電子署名やeシール用のX.509証明書を発行してもらえば、DIDの秘密鍵で署名されたVCやデジタル署名は、法的効力を持つと言うことです。did:webのところでも言いましたが、「分散型」を標榜しつつも、やはり過去からの互換性を維持するため、または効率性の問題で「中央集権型」に、ある程度依拠せざるを得ないと言うことなのかなと思います。

さて、Catena-XやGaia-Xにおける、この「中央集権型」VS「分散型」問題を見て行きましょう。前述したように、Catena-Xへのオンボーディング（企業の参加）における「身元確認」は、Gaia-Xのサービス（GXDCH）に委ねられてます。Gaia-XのGXDCHとトラストアンカーに関する説明の図の中に、私の解説を加えたものを以下に示します。

上記の通り、Gaia-XのGXDCHに申請する場合は、GLEIF（Global Legal Entity Identifier）やVAT ID（付加価値税納税者番号）を明記して申請し、それによってGaia-X側が企業の実在性を確認した上でVCを発行するようです。そして、VCを受け取った申請者が、消費者（サービス利用者）として、サービス提供者（Catena-Xの運営主体や、Catena-X上でのサービス又はデータ提供者）にVPとして提示して、サービスを利用したりデータの送受信を行うと言うことのようです。ただし、ここで先ほど説明したような、DIDの公開鍵とX.509証明書の紐付けについては、明記されていなかったので、今後実際にCatena-Xのオンボーディングプロセスで確認して行きたいと考えています。

さて、実は上記の図には見逃せない記述があります。それは、「又はEV SSLの発行事業者」とあることです。EV（Extended Validation）とは、先ほど説明したLet's Encryptのような、ドメイン名の所有証明程度の身元確認で発行される証明書ではなく、より厳密な組織の実在性確認を経て発行されるSSLサーバ証明書のことです。先ほど「IDトラスト」の章で説明したIALは、自然人に対する身元確認の保証レベルなので、厳密に言うと違いますが、例えば「ドメイン名の保有証明」がIAL2で、より厳密なGLEIFやVAT IDと、それを証明する（書面又は電子の）登記簿のような文書による確認がIAL3と言うイメージで、後者がEV SSLに相当する感じでしょうか。もしかすると、欧州では既にVCを発行するEV SSL事業者が存在するのかも知れませんが、仮に旧来のX.509証明書でも、先ほどのDIDとの紐づけを利用することで、同様の効果を得ることが出来そうです。それ以前に、今は未だ揺籃期と言うか、「試行期間中」と言うことで、実質GXDCHが唯一のVC発行機関なのかも知れません。EV SSL事業者がX.509証明書を発行することを想定しているかのような図がGXDCHの文書にありました。

上記の図の左から2番目に、「Mozilla CA Certificate List」と言う箱があります。まさに、ブラウザのMozillaに信頼済みとして登録されたCA証明書のリストを参照すると言うことで、普通に従来のX.509証明書や階層型CAモデルにも対応しようとしていることが推測されます。

データスペースの国際連携に向けて

日本でも欧州電池規則への対応を切っ掛けとして、蓄電池のCO2排出量集計や将来的な電池パスポートの実現に向けた「ウラノスエコシステム」の構築と整備が進んでいるようです。欧州電池規則に対応するためには、欧州規制当局に日本企業が関与した電池の部品情報や完成品情報等を提出し、真正なものと認めて貰う必要があります。Gaia-XやCatena-Xの背後には欧州加盟国の政府、もっと言うと規制当局が居ますので、欧州電池規則への対応だけを目的と考えると、Catena-Xに直接参加して、データを提出するのが早道でしょう。しかし、日本の自動車や電池の関連産業は裾野も広く、そもそも前述したような身元確認に必要なGLEIFやVAT IDを取得していない企業も多いと思われるため、システム実装的な意味でも中々ハードルが高いものと思われます。更に、Catena-Xのデータ利用条件の合意に基づく「契約」の概念を良く理解していないのか、外国の法体系なので信用していないのか、いずれにせよ「データ主権」や「自己主権」的な考え方で、日本独自の仕組みを作ろうと言う判断に至ったのかなと想像します。

その判断の是非は問いませんが、日本独自の仕組みを作るにしても、やはり先行して検討が進んでいる欧州データスペースの考え方（データは所有者自身が持って、利用条件を相手と合意した上で交換する）や、国際標準化に向けて動き出しているデータスペースプロトコル、更にそれを実装するIDS/EDCコネクタに準拠して設計・実装すべきだと思います。私は単に欧米が中心となって確立した国際標準規格に盲従しろと言っているのではありません。昨年の4月に私はドイツを訪問して、ドイツの経産省に当たるBMWKでGaia-Xを推進する方々とお会いしてきましたが、彼らが技術的にも広く深い知見を持っていることに感銘を覚えました。官民交流が盛んで、技術的なバックグラウンドを持つ方々が多く政府組織に関与しているのかも知れませんが、技術者目線で妥当だと思えることを、しっかりと政策立案や国際的な技術標準の確立に活かして行く戦略を強く感じました。しかし、それらの技術標準も未だ完璧ではありません。例えば、先ほど説明した、EDCコネクタによるデータ送受信者間のデータ利用制御（Usage Control）においても、飽くまで「契約」ベースであり、相手にデータを渡した後のデータ利用制御等において、技術的にもう少し出来ることがあるように思います。また、先ほども指摘したように、IDSコネクタやEDCコネクタ間の送受信データや契約へのデジタル署名についても、現時点で明確な規定は見当たりません。日本からも、これらの国際標準規格の策定に積極的に関与して行き、日本固有の要件も主張して行くべきではないかと思います。

このように、現在検討されているデータスペース関連の国際標準規格の策定にも関与しつつ、今まで述べて来た「IDトラスト」や「データトラスト」の考え方を理解して、日本と欧州と言う国際間における、トラストフレームワークやアーキテクチャをある程度揃えた上で、信頼の基点であるトラストアンカーの相互認証と相互連携を図るべきです。今年の4月にも、「日EUデジタルパートナーシップ閣僚級会合」が開催されたようですので、そのような枠組みを最大限活用して、議論を進めて欲しいと思います。

長年の運用経験で実績のある中央集権型のPKI（CAモデル）と、最近登場して来た「データ主権」「自己主権」を標榜する分散型のDIDを橋渡しする方式は、先ほど説明した通りです。したがって、国際間の相互認証については、古くからある中央集権型のPKIベースで実現すれば良いと言うのが私の意見です。

上記は、JNSA（日本ネットワークセキュリティ協会）の「トラストのためのデジタル署名検証解説」からの引用となります。図中の上部のTrusted Listと言うのが、先ほど出て来た「eIDAS適格トラストサービス」の認定CAリストです。これを日本でも定義し（電子署名については、既に電子署名法の認定認証業務一覧が存在）、日本と欧州の双方で認定基準の互換性を合意した上で、双方のTrusted Listを参照し合うような形にすれば、国際間の相互認証が実現できます。前述のように、電子署名法の認定基準における設備要件等はWebTrust for CAに準拠していますし、eIDASの適格トラストサービスもある程度WebTrust for CAを参照しているはずなので、それほど難しいことはないと思います。大きな課題は、日本における法人の実在性確認のための法人番号やベースレジストリが、未だ整備の途上にあると言う点でしょうか。

ソフトウェアトラストとその展望

最後に、ソフトウェアトラストの話をしたいと思います。ソフトウェアを、単なるプログラム言語で記述されたソースコード又はそれをコンパイルしたバイナリ（機械語）のデータと捉えると、ソフトウェア開発者が付したデジタル署名を検証することにより、正当な開発者によって開発・提供されたソフトウェアであることを検証した上で実行するような仕組みは既にあります。例えば、Windowsのデバイスドライバは、Microsoft社の認定CAがソフトウェア開発者に対して発行した「コード署名証明書」に対応する秘密鍵で署名されている必要があります。また、iPhoneやiPad上で動くアプリをApp Storeで広く一般公開するためには、Apple社から開発者用の証明書を取得し、開発環境でアプリにデジタル署名を付し、アプリの機能についてApple社の審査を受ける必要があります。欧州や日本では独占禁止法に抵触すると言う議論がありますが、その審査基準が公開されて、かつ公正に運用されていれば、Apple社の審査を経ている分、当該ソフトウェア（アプリ）に対する信頼（トラスト）は、単なる開発元の認証よりも高いと言えるでしょう。

したがって、既に「ソフトウェアトラスト」を実現・強化して行く素地はある程度整っていると言えます。しかし、ソフトウェアはどんどん複雑化・巨大化しています。例えば、WindowsやAndroid等の汎用OSのソースコードは数千万行、更に自動運転等のネットワーク接続機能を持つ自動車に搭載されるソースコードは数億行に達すると言う話もあります。そのような大規模なソフトウェアは、丸っとモノリシック（一枚岩）な構造で構築出来る訳もなく、多数のOSSライブラリや商用パッケージの組み合わせで構築されることになるでしょう。そのような大規模なソフトウェア全体に対して、何らかの審査基準に沿って、一貫性を持った高いレベルの認証を与えるのは極めて難しいと思います。2020年のSolarWinds事件に端を発し、バイデン大統領は連邦政府調達のソフトウェアに「セキュリティ・バイ・デザイン」を求める大統領令に署名しました。この中で注目を浴びたのが、ソフトウェア部品表（Software Bill of Materials。以下SBOM）です。

上記は、NRIセキュアによるSBOMの解説からの引用です。つまり、あるソフトウェアを構成するOSSや商用パッケージを「部品」と見立てて脆弱性等を管理しようと言うことです。先ほどのバイデン大統領令によると、米国政府調達のソフトウェアにはSBOMを添付することが求められますし、最近成立した欧州サイバーレジリエンス法では、欧州で販売されるデジタル製品に対して脆弱性管理のためにSBOMを作成することが求められます。

SBOMを作成・公開するだけでも、ソフトウェアに対する信頼は増すと思うのですが、より一層高めるにはどうしたら良いでしょうか？一つには、上記の図の中に「タイムスタンプ」とありますが、同様にこの章の冒頭でお話したような、コンポーネントに対するデジタル署名、すなわち「コード署名」を付すると言う考え方もあります。ただし、コンポーネントがOSSの場合、OSSの開発コミュニティが「コード署名証明書」を取得して署名してくれるかと言う課題はあります。今後、コンポーネントの開発元をデジタル署名で検証するのが一般的になれば、OSSのコミュニティまたはコミッター（ソースコードの修正や新機能の追加などの承認権のある技術者）が「コード署名証明書」を取得するのが一般的になるかも知れません。

また、「トラストの定義」でも述べたように、開発元のソフトウェア開発プロセスにおけるセキュリティや内部統制が確保されていることを、前述のSOC1/2やISMS（ISO-27001）等の一定の監査基準に基づく第三者認証を取得済みであることを確認した上で発行するような「プレミアムなコード署名証明書」を作って、より高度なセキュリティが要求されるシステムは、そのようなコード署名を持つソフトウェアでなければ起動出来ないようにすることも考えられます。この場合は、個別のコンポーネントの開発元と言うよりも、それらを組み合わせたソフトウェアの開発元（SI事業者）として証明書を取得し、ソフトウェア全体に対してコード署名を付するイメージでしょう。ただし、この方式の場合、開発元のソフトウェア開発プロセスのセキュリティや内部統制が一定の基準を満たしていると言うだけで、実際に開発されたソフトウェアそのものを検証した訳ではないことに注意が必要です。そこで、先ほども述べたApple社のApp Storeのように、一定の基準を持って公正にアプリ（ソフトウェア）のセキュリティや品質を審査した上で提供されるのが理想的です。しかし、Apple社の方式は独占禁止法的な懸念もあります。ある程度、自由競争に委ねながら、ソフトウェアのトラストを担保するにはどうしたら良いでしょうか？実は、前の章までの議論の中にヒントが隠されています。

それはまさに、ソフトウェアを対象とするデジタルプロダクトパスポート（DPP）を作ることではないかと思います。電池パスポートは、原材料の採掘事業者や部品の製造業者が、それぞれの採掘・製造工程で排出されたCO2の量や部品材料の組成をVC（検証可能クレデンシャル）として証明するのと同時に、例えば外部の監査機関が採掘工程で人権侵害に繋がるような不当労働行為が行われていないことを監査した上で、その意見をVCとして表明する仕組みでした。全く同様の考え方で、例えばソフトウェア全体や個別のコンポーネントの要件（仕様）に対して、開発・テスト工程で然るべき品質保証を行ったことの表明（具体的な仕様やテストの内容を含む）を開発元がVCとして発行したり、ソースコードの脆弱性検査を行って問題が無いことをセキュリティ事業者がVCで証明して、それらをソフトウェアに対するDPPとして発行するようなことも考えられると思います。

セキュリティや品質の基準としても、情報システム（ソフトウェア）に対するセキュリティ評価基準であるISO/IEC 15408 (Common Criteria)の高いEAL（Evaluation Assurance Level。評価保証レベル。EAL1～EAL7がある）や、形式検証（今回のAdvent Calendarにタイムリーな記事があります）のような数学的に厳密な検証を受けた結果をVCとして取得し、それを提示することで高い信頼を得ることが出来ます。一定の基準以上のVCが揃っていないと、そのソフトウェアが実行出来ないような制御も可能だと思います。また最近、強力になりつつあるAIの「暴走」を懸念して、AIを組み込んだシステムの安全性の確保や、学習データの偏りによる偏見や差別をなくす、「AI ガバナンス」や「AI規制」と言った議論も、主に政府系を中心に盛んです。個人的には、それ以前にAI開発・提供人材の育成や、企業におけるAI活用促進の方が先ではないかと思わないではありませんが。こちらも同様に、AIの安全性やセキュリティ、学習データの扱いや出力の精度に関する一定の評価や監査の基準を設けて、その結果を同様にVCとして証明する仕組みが考えられると思います。

情報秘匿や知財保護の観点から、詳細なテストや検証の内容と結果を公開したくないと言う、「データ主権」「自己主権」的なニーズもあるでしょう。それも、DID/VCであれば、今回は解説しませんでしたが、VCの選択的開示やゼロ知識証明と言う技術でカバー出来ます。

おわりに

軽い気持ちで書き始めた記事でしたが、気付けば私の「PKI技術者」としての集大成とも言える大作（←大袈裟）になってしまいました。ここまで読んで下さった方、本当に有難うございました。生成AIに若干押され気味の「ブロックチェーン」や「web3」ですが、前述したように広い意味でのPKIだと思っています。この記事を読んで、少しでも「トラスト」や、その基盤技術であるPKIに興味を持つ方が増えてくれれば、望外の喜びです。

1. https://initiatives.weforum.org/digital-trust/home ↩

2. https://trustedweb.go.jp/about/ ↩

3. https://www.digital.go.jp/policies/dfft ↩

4. https://warp.ndl.go.jp/info:ndljp/pid/12308150/www.ipa.go.jp/security/pki/index.html ↩

5. 説明の便宜上、ここではRSA暗号による鍵交換方式の図を引用しましたが、計算機の能力が大幅に向上している昨今、過去の暗号文を大量に蓄積しておくことで、秘密鍵の漏洩や将来的な量子コンピュータの実現によって解読されるリスクが認識されるようになり（特に、2014年に見つかったOpenSSLの脆弱性"Heartbleed"以来）、RSA暗号は使われないようになりました。このリスクを回避できる暗号の性質を、Perfect Forward Secrecy（PFS）と呼びます。 ↩

6. https://ja.wikipedia.org/wiki/X.509 ↩

7. https://ja.wikipedia.org/wiki/%E3%82%AB%E3%82%B6%E3%83%95%E3%82%B9%E3%82%BF%E3%83%B3%E6%94%BF%E5%BA%9C%E3%81%AB%E3%82%88%E3%82%8B%E4%B8%AD%E9%96%93%E8%80%85%E6%94%BB%E6%92%83 ↩

8. https://ja.wikipedia.org/wiki/2011%E5%B9%B4%E3%83%87%E3%82%B8%E3%83%8E%E3%82%BF%E3%83%BC%E4%BA%8B%E4%BB%B6 ↩

9. Electronic Identification, Authentication and Trust Services ↩

10. 勿論、その匿名性の高さ故に、マネーロンダリングやランサムウェアにおける身代金の授受に悪用されている側面はあるので、口座開設時の身元確認等、運用面での対策が重要なことは申し添えておきます。 ↩

11. https://www.nri.com/jp/news/info/cc/lst/2024/1016_1 ↩