AKI Whitepaper・Web3.0時代の暗号基盤

AKIのコンセプト

高度にデジタル化された現在では、企業が扱う情報はその企業のビジネスそのものの価値であると言えます。ビジネスの規模が大きくなればなるほどに扱う情報の重要度も高まり、その高まりに呼応するように情報の取り扱いに対する市場の目は厳しくなるばかりです。
デジタル化の恩恵を主張し効率アップを求める声がある一方、デジタル化のリスクを主張し警鐘を鳴らす声もあります。両者の主張は平行線となり交わることがありません。突き詰めれば、システムを構築しサービスを提供する側を信用できるか否かが問われている様に思えます。

現状、「サービスを提供する側は過ちを犯さない」という前提の下、社会が成立しています。その前提が崩れた時、サービスを提供する側のみならず、サービスを受ける側も深刻なダメージを負うこととなります。サービスを受ける側は被害者であるとしても、サービスを提供する側の賠償能力を超える補償は受けられません。生産効率を追求し、世界規模でサプライチェーンを構築している工業製品は、部品一つ欠けるだけで生産停止に追い込まれることは周知の事実でしょう。欠品を起こし、生産停止の原因となった一企業に全責任を負わせ全損失を補償させるのは無理があります。サプライチェーンに組み込まれた一企業に求められる責任は、一企業で補償できる範囲を逸脱しつつあります。

ネットワークの世界も同じです。利便性や効率を優先し、情報の統合、連携が求められています。ですが、情報が漏えいしていないこと、改ざんがないことを誰が保証し、どうやって連携したシステム全体の健全性を確保するのでしょうか。ネットワークの世界も最終的に誰も責任を負えず、実質、野放しになる世界へと向かっている様に思えてなりません。

お気づきでしょうか。たとえ、自社の管理体制を整えたとしても、市場からの信頼を得られなければ意味がありません。自社のシステムが他社のシステムに依存するのであれば、他者のシステムの管理体制までも含めて整えなければ意味がありません。サービスを提供する側は、サービスが確かな証拠を保持する事で、不正がない事を示せなければなりません。
サービスを受ける側が、受け入れたサービスが信頼に値するものであるか、いつでも確認できる状態でなければなりません。
利便性や効率を追求しデジタル化が進む現在、安全で自由な情報交換が出来、かつ、サービス提供側を過信せず、サービス受給側からも検証できるシステムが市場から求められているのではないでしょうか。

情報には「情報を作る人」と「情報を読む人」が存在します。サービスを提供する側、受ける側という役割で区分するシステムではなく、情報を作る側、読む側とで区分するシステムとして構築することにより、役割の垣根を超えた情報管理が可能となります。 AKIは情報を中心に置き、役割の垣根を超え、参加者全員で自らを統制できる「情報システムのセルフガバナンス」を実現します。まだ見ぬ脅威におびえ神経質に対策せざるを得なかった従来の情報管理の在り方に一石を投じるものと確信しております。

AKI：Asymmetric key Infrastructure / 非対称鍵暗号基盤
セルフガバナンス：外部からの影響を受けることなく自ら規律を定め自らの意思で自らの行動を律すること。

セルフガバナンスの推進

AKI は、セルフガバナンス推進のために、3つのコンセプトを提案します。

役割中心から情報中心へのパラダイムシフト
- 作り手/読み手モデルの提案
唯一性の創出
- 作り手/読み手/持ち手モデルの提案
ログ情報基盤の構築
- 分散ログ情報

役割中心から情報中心へのパラダイムシフト

現在、広く採用されているソフトウェアモデルとしてクライアント/サーバーモデルがあります。このソフトウェアアーキテクチャモデルは役割を中心にデザインされたモデルです。「作り手/読み手モデル」は「情報」を中心に捉え、作成と検証、そして所有に着目して新たにデザインしたソフトウェアアーキテクチャモデルです。

作り手とは
- 情報を作る事が出来ます
- 相対する読み手がいます
読み手とは
- 情報を読む事ができます
- 作り手が作った情報を原本として預かる事ができます
- 相対する作り手がいます

作り手/読み手モデルの実現には非対称鍵暗号技術が最適です。
しかしながら、非対称鍵暗号基盤として最もメジャーである PKIは、役割分担を中心におきデザインされている為、情報を中心としたモデルとの相性が良くありません。

PKI：Public Key Infrastructure / 公開鍵暗号基盤

そこで、作り手/読み手モデルに最適化したデザインを施し完成した暗号基盤が AKIです。本書は、コンセプト説明なので、暗号技術の詳細は極力排除いたしました。暗号技術によりもたらされる効果を現実のオフィスワークに結び付けてイメージできるように作り手による暗号化処理を「押印」、読み手による復号処理を「検印」と表現します。

作り手は、読み手にデータと押印済み保証書を送付する
- データから保証書を作成する
- 作成した保証書に作り手鍵で押印する
読み手は、作り手からデータと押印済み保証書を受け取り、検印する
- データから仮の保証書を作成する
- 受け取った押印済み保証書を読み手鍵で検印する
- 検印した押印済み保証書と仮の保証書が一致するか確認する

検印した押印済み保証書と仮の保証書が一致していれば、データは作り手が作成した情報である。

本書での解説は割愛しますが、保証書の押印/検印と同時に、データを暗号化/復号することも可能です。パスワードレスで情報の暗号化/復号を行いますので、パスワード流出を懸念する必要はありません。

パスワードレスで暗号化/複合化する技術は、ゼロ知識証明技術（Zero Knowledge Proof：機密情報を明かさずに証明する技術）として知られています。

作り手/読み手モデルの概要

AKI による作り手/読み手モデルの具体例を説明します。
従来モデルでは役割が中心であり、クライアントもサーバーもそれぞれが情報の作り手であり読み手でした。情報に着目すると、クライアントからサーバーへのリクエストは、クライアントが作り手、サーバーが読み手となります。そしてレスポンスでは逆の関係です。これらを踏まえ、「図 1 AKI の概要」を参考に従来モデルに適応した図を示します。

クライアントからサーバーへのリクエストを赤色の鍵セット、サーバーからクライアントへのレスポンスを紫色の鍵セットとして、表現しています。それぞれのデータには保証書が添付され押印が施されています。読み手は、保証書を検印処理し、受け取ったデータの真贋を判定します。

データ作成と参照を中心に据えることで非常にシンプルなデータフローとなりました。特筆すべきは、クライアントとサーバー間を AKI の暗号/復号オプションを使う事で E2Eセキュリティが構築できる事です。このシンプルで堅固な E2E データ交換プロセスが、作り手/読み手モデルの基礎です。

E2E：End To Endの略、通信を行う二者、あるいは二者間を結ぶ経路全体を指す

作り手/読み手モデルの特徴を絵図として以下にまとめました。

AKID：読み手鍵を指し示すID情報

上図は、一つのAKIDでリクエストとレスポンスの鍵ペアをまとめています。
取りまとめる事でAKIDがクライアントとサーバーのE2Eの関係性を抽象します。

唯一性の創出（情報の認証）

シンプルな E2E データ交換の仕組みが整いました。
続いて、データを「情報」として取りまとめ共有する仕組みを深掘りします。

情報とは取りまとめられたデジタルデータの集合体と定義します。
情報は、保存し、共有し、コピーし、配布する対象です。
デジタルデータはネットワーク、物理媒体を介して流通します。
情報の流通過程に潜在する脅威への対処が、現在のセキュリティ対策の柱の一つとなっています。

AKI は、情報が「作り手の意図した唯一のものであること」を保証することが、根源的なセキュリティ対策につながると考えました。そこで「相互押印」という独自技術で、この「唯一性」を確保しました。相互押印とは「相互に一度だけ押印した特別な保証書を作ること」です。本書ではこの保証書を「デジタル証書」と表します。

相互押印：特許 7100330 押印管理方法、押印管理装置、プログラム、及び情報処理方法

相互押印

相互押印の手続きは、作り手と読み手との印鑑リレーに例えることができます。

Whitepaper-04 — ***図 4 デジタル証書と情報、押印関係の概要図***

情報の作り手が保証書を作成し、情報・作り手鍵で押印した後、読み手に渡す
情報の読み手が保証書の正当性を確認した後、証書・作り手鍵で押印したデジタル証書を作り手に渡す

作り手の手元には、情報と読み手が押印したデジタル証書が残ります
デジタル証書には作り手が押印した保証書が同梱されています

この押印リレーをデジタルデータに適応させたものが相互押印です。
相互押印自体は、伝統的に紙媒体で行われている手法を元にした、非常にシンプルな仕組みです。

しかしながら、デジタルデータに適応すると少々難解です。そこで、本書では、最初に単純なモデルで説明します。そして、そこにある問題点を示した後に改善策を示すことで、相互押印の基本構造の説明につなげていきます。ご承知おきください。

Whitepaper-05 — ***図 5 相互押印のイメージ図（問題点があります）***

クライアントとサーバーとのデータ交換については「作り手/読み手モデルの概要」で説明した内容が当てはまります。
リクエストが赤枠、レスポンスが紫枠で抽象化しています。
情報がオレンジ色の情報・鍵セット、証書が青色の証書・鍵セットで表現しています。
取り扱いの対象が、データからデータの集合である情報となっています。

保証書の作成と押印依頼
- 情報から保証書を作成する
- 保証書に情報・作り手鍵で押印する
- 作成した保証書をサーバーへ送付する
  - 本ケースは、デジタル証書の作成が目的なので、情報は送付しない
サーバーの押印処理
- 情報・読み手鍵を使って、保証書を検印する
  - 保証書が正しい事を確認する
- デジタル証書を作成する
  - 情報・作り手鍵で押印された保証書を内包する
- 証書・作り手鍵で、デジタル証書を押印する
- 作成したデジタル証書をクライアントへ送付する
クライアントの検印処理
- 証書・読み手鍵を使って、デジタル証書を検印する
- 検印できたら、デジタル証書は正しく作成されている

「図 5 相互押印のイメージ図（問題点があります）」において、赤色のリクエスト・鍵セットと紫色のレスポンス・鍵セットを使って押印者を特定できますが、これはE2E のための鍵なので相互押印には別の鍵で表す必要があります。そこで、新たにオレンジ色の情報・鍵セットと青色の証書・鍵セットを用意し相互押印専用の鍵として表現しました。

相互押印に使用する情報・作り手鍵と証書・作り手鍵に着目すると、三つの課題があることが分かります。

一つ目は、「クライアントは証書・読み手鍵でしかデジタル証書の検印ができない」ことです。クライアントが情報・読み手鍵も所有すると非対称鍵の関係性が壊れてしまいます。
また、第三者が情報をデジタル証書で検印する際には、情報/デジタル証書/証書・読み手鍵/情報・読み手鍵をセットで渡す必要があります。

二つ目は、「検印結果の共有ができない」事です。
作り手と読み手、さらに第三者の読み手との間で検印結果の共有ができなければ、情報が意図しない形で流通していることを検知し対策する事ができません。

三つ目は、「唯一性の欠如」です。
相互押印に直接使用するオレンジ鍵と青鍵は、デジタル証書の作成に使い続ける形で描かれています。この仕様では情報の改ざん検証しか行えず、情報の認証には適切ではありません。なぜならば、内容が全く同じ複数の情報を認証するケースが想定される
からです。たとえ同じ情報であっても事象としては異なり、唯一無二な存在なのです。
この唯一性を検証できるデジタル証書が情報の認証には必要です。

唯一性：ただ一つである事

鍵を使い続けるリスクはこれだけではありません。作り手鍵が漏えいした場合、作り手鍵を入手した者が不正なデジタル証書を作成できることになり、漏えいした作り手鍵で作成した過去全てのデジタル証書の信頼を失います。

作り手/読み手/持ち手モデル

これらの課題を解決するため、相互押印ごとに常に新規に鍵を作成し、鍵の生成破棄、鍵の所有関係を見直しました。
以下のフローをご確認ください。

Whitepaper-07 — ***図 7 相互押印の改良イメージ/デジタル証書の作成***

デジタル証書の作成ステップは以下の通りです。
変更された事項はオレンジマーカーで強調しています。

保証書の作成と押印依頼
- 情報・鍵セットを新規作成する
- 情報から保証書を作成する
- 保証書に情報・作り手鍵で押印する
- 作成した保証書と情報・読み手鍵をサーバーへ送付する
  - 本ケースは、デジタル証書の作成が目的なので、情報は送付しない
- 情報・作り手鍵は廃棄が望ましい
サーバーの押印処理
- 証書・鍵セットを新規作成する
- 情報・読み手鍵を使って、保証書を検印する
  - 保証書が正しい事を確認する
- デジタル証書を作成する
  - 情報・作り手鍵で押印された保証書を内包する
- 証書・作り手鍵で、デジタル証書を押印する
- 作成したデジタル証書をクライアントへ送付する
- 証書・作り手鍵は廃棄する
- 情報・読み手鍵と証書・読み手鍵が保存されている
デジタル証書を受領する
- 証書・読み手鍵を持っていないので検印はしない

「図 7 相互押印の改良イメージ/デジタル証書の作成」では保証書/デジタル証書の作成に新規作成した鍵セットを用い、検印に使用する情報・読み手鍵、証書・読み手鍵をサーバーが保持しています。

一つの情報に対し保証書/デジタル証書の作成は一度だけですから、情報・作り手鍵、証書・作り手鍵を保持する必要はありません。では、作り手鍵を保持し続けた場合、悪用は可能でしょうか。保証書/デジタル証書の作り手は、作成後、相手に渡してしまうため、相手に渡した保証書/デジタル証書を差し替える術はなく、悪用はできません。利用価値のない鍵は安全性の観点から破棄すべきでしょう。不要な鍵を破棄する事で、より確かな唯一性を得る事ができます。

説明簡素化のため暗号化は割愛しましたが、デジタル証書に内包する保証書を暗号化し、証書・読み手鍵を持たない者が保証書を読めない状態にすることも可能です。

デジタル証書を受け取ったクライアントは情報の作り手としての役割を終えます。
この、情報とデジタル証書を所有している状態を「持ち手」と定義します。持ち手はクライアントのみならず、別の第三者でもかまいません。

作り手とは
- 情報を作る事が出来ます
- 相対する読み手がいます
読み手とは
- 情報を読む事ができます
- 作り手が作った情報を原本として預かる事ができます
- 相対する作り手がいます
持ち手とは ←New（新しい情報所有の概念）
- 情報を所有しています

続いて、持ち手視点での検証フローを示します。
情報とデジタル証書しか所有していない状況で検印ができれば、作り手/読み手/持ち手モデルの完成です。

持ち手のリクエストが緑枠、レスポンスが灰枠で抽象化しています

デジタル証書の検証ステップは以下の通りです。

デジタル証書の検印依頼
- 情報から仮の保証書を作成する
- 仮の保証書とデジタル証書をサーバへ送付する
デジタル証書の検印
- 証書・読み手鍵を使って、デジタル証書を検印する
- 情報・読み手鍵を使って、デジタル証書内の保証書を検印する
- デジタル証書内の保証書と仮の保証書を比較する
- 一致すれば検印 OK、不一致で検印 NG
検印依頼の結果を受領
- 検印結果を受領

持

持ち手は仮の保証書とデジタル証書をサーバーに送ることで、検印結果を得ることができます。
説明簡素化のため暗号化は割愛しましたが、情報を暗号化し、サーバーにデジタル証書の検印を依頼しなければ情報を復号できない状態とすることも可能です。この場合、クライアントはサーバーからデジタル証書の検印結果に加え、復号に必要な鍵を受け取ることです。情報の暗号化は、流通過程に潜在する脅威への対策として効果的です。

情報とデジタル証書をセットにして、自由にコピーして配布して共有する事が可能です。唯一性確保と暗号化により、サーバー管理の下、全クライアントを識別した上で、情報とデジタル証書のセットで情報を安全に流通させる手法を示しました。
サーバーは全てのクライアントを識別しますので、特定のクライアントにのみ、情報を閲覧が可能(復号が可能)にすることも、情報を閲覧が不能(復号を禁止)にすることも容易です。さらに、意図しないクライアントからの閲覧要求があれば、意図しないルートで情報が流通していることを把握できます。

本手法のシステム要件上の特徴は以下の通りです。

サーバーは「鍵の関係性管理」と「鍵へのアクセス管理」が主機能であり、コンパクトなシステムである
クライアント/サーバー間の通信内容は主に保証書/デジタル証書と鍵となるため「通信量が少なく済む」

作り手/読み手モデルに、持ち手という概念を組み込むことで、情報を、安心／安全に、保存し、共有し、コピーし、配布できる仕組みが整い、「セキュアなデータ管理が可能なソフトウェアアーキテクチャモデル」へと広げる事ができました。

作り手/読み手/持ち手モデルで扱われる情報は、そのライフサイクルにおいて適切に保証される情報です。
作り手/読み手/持ち手モデルは役割ではなく情報が主体なので、自社だけでなくサプライチェーン全体のセルフガバナンスに結び付きます。

ログ情報基盤の構築

シンプルで堅固なデータ交換プロセスが確立し、情報を安全に流通させる事ができました。最後のコンセプトは「セルフガバナンスが可能な情報基盤」の実現です。
ガバナンスは、組織における不正行為を未然に防ぎ体制管理をするために不可欠です。情報システムは、定期的に情報システムのログを収集し、適切な運営がなされているのかを監査します。監査結果を運営にフィードバックする事でガバナンスが保たれます。

セルフガバナンスが可能な情報基盤：特許7144020　情報処理方法、サーバ、及びプログラム

しかしながら、「ログを収集し監査する」作業は言うほど簡単ではありません。
単なるテキストの積み上げで作られたログの改ざん有無を判断するのは容易ではなく、ログを分析し、矛盾がないか調査するには膨大な作業時間と高い専門性を必要とします。
また、ログの多くは公開を前提にしておらず、ログ自体に機密が記録されているために、第三者を交えた監査が難しい状況に陥る事もありえます。この様なシステム監査の在り方を変えなければなりません。

本項では作り手/読み手/持ち手モデルをログにも適用し、ログ開示を意識した作成へのパラダイムシフトを提案します。
ログの読み手を想定し、見せられないカ所を暗号化するなど、用途に応じた記録方法を用い、クライアントのログ開示要求に答えられるログを作成した上で、それらをハッシュチェーンで結んで連続性を確保します。
さらに、ログ毎ごとに算出されるハッシュチェーンの値をデジタル証書に含めることで、サーバーのログ情報をも監査できるデジタル証書が完成します。

ハッシュチェーンの値を含むデジタル証書は、サーバー側はクライアントからの検印要求時に自身のログ情報監査に活用でき、クライアント側はサーバーからログ情報を入手し、自身の持つデジタル証書と照合することでサーバーが適切に運用されているかを監査できます。

作り手と読み手のデータフローをログ情報として記録する
その際、ログ情報には、ログの読み手を意識した形で記録する
読み手はログ情報に連続性を持った情報を割り印として押印する
割印情報を持った控えのログ情報をデジタル証書に埋め込む

サーバー側によるログ情報検査
- 情報の検印時に送付されるデジタル証書内のログ控えを使って、ログ情報の割印検査と、割印ハッシュチェーンによる連続性検査が出来ます
- ログ情報検査に不適合を検出したら、即、不正検出と判断可能です
- E2E が確保されているので、誰が、いつ、どの様な操作を行ったのか、など、
  ログに記録されていれば細かなトレーサビリティを検証するも可能です
クライアント(読み手/持ち手)側によるログ情報検査
- サーバー側からログ情報と割印ハッシュチェーンの提供を受けることにより、デジタル証書内のログ控えを使って、ログ情報の割印検査と割印ハッシュチェーンによる連続性検査が出来ます
- ログ情報検査に不適合を検出したら、即、不正検出と判断可能です
- クライアント単独での検査も可能ですが、他のクライアントの保持するデジタル証書を集めることで、より信頼度の高い検査が出来ます

AKI が提案するデジタル証書は、唯一性による証拠能力と、サーバー／クライアント双方で検証に活用できるという特徴を持ちます。そして、「決して信頼せず、常に検証する仕組み」であるゼロトラストを指向したシステムです。デジタル証書を蓄積し、サーバー／クライアント双方で検証することにより、容易に持続が可能なセルフガバナンスが実現されます。

総括

AKI は「デジタル証書を用いた情報の自由な取り扱い」と「割符ログを用いた相互検証できる情報システム」を提供します。それは、サービス提供者を全面的に信頼する従来型のシステムではなく、サービス提供者と利用者の双方で信頼性を確保し検証できる新しいセルフガバナンス・システムです。

サービス提供者を全面的に信頼する従来型のシステムは、信頼を寄せたシステムの信頼性を問われた時、さらに別のシステムに信頼を求める必要があります。サービスの提供者と利用者により支えられるセルフガバナンス・システムには、全面的に信頼を寄せる相手は存在しません。また、一つの鍵に依存するシステム、もしくは、一カ所に全てを集約するシステムは、一つのほころびで全てが崩壊します。一方、情報ごとに鍵を生成し、鍵と情報とを分けて保持するシステムは、一つのほころびだけでは全崩壊には至らず、被害は限定的です。不正を試みる者にとって、費用対効果が悪いものとなるでしょう。

個別に鍵を割り当てられた機器間で E2E 通信を行い、誰が作った情報であるか、誰が読む情報であるかを区別する強力なトレーサビリティを実現します。情報の作り手から、情報を得るべき相手に、情報を E2E で受け渡すことが可能です。鍵の集中管理、情報とログの分散保持を組み合わせた、当事者同士で信頼できるセルフガバナンスを指向したシステムは、今後、新たなシステム形態として発展していくものと確信しております。