はじめに
いよいよAKI最後のレイヤ「分散ログ」の解説です。
SureArchiverを運用するシーンにおいてもゼロトラストを想定した設計が必要です。万が一、運営組織が信用出来なくなってしまったとしても、それを検知できる事こそが正しいゼロトラストへの対応です。システム自体が「倫理的で社会的責任を果たす（エシカル：Ethical）」を指向した設計であれば、おのずと運営組織に「セルフガバナンス」が醸成され、たとえゼロトラストであっても破綻する事はありません。本書では、「エシカルな運用」の基盤となるべく設計した分散ログについて説明します。
エシカルなシステム運用とは
エシカル（倫理的）なシステム運用とはなんでしょうか。システムは常に健全で、秘密を持たず、だれでもが検証できる運用を示すのだと考えます。しかしながら、現状は、まず「秘密はあります」。そして「運営が統制して検査」する仕組みで構成されています。どうしても倫理的な運用は運営に依存するので、運営の組織的改ざんには為す術もありませんでした。ですから「運営自体もトラストレス」を前提にする事でこの課題を解決したいと考えました。
まず、AKI TLSとAKI Archiverをつかって情報から「秘密」をなくします。さらに、SureArchiverをつかって情報認証を行い情報に唯一性を与えます。この時のやり取り（トランザクション）を「証拠」にできれば「情報の作り手主体」で「持ち手が検査」できます。運営が統制しなくともシステムの検査が可能となることで、自らを律する「セルフガバナンス」を醸成し「エシカルな運用」へとつながります。この、エシカルな運用を実現するために考案した仕組みが「分散ログ」です。
従来型のトランザクションログ
従来のシステムのログは、システムごとにサイロ化が進む傾向にあります。機密情報がログから分離されていないケースも多くありますし、ログの解析にも専門知識が必要なケースがほとんどです。
一般的なトランザクションログについて
一般的なトランザクションログを図にまとめました。かなり簡素化しましたが、一般的にはこの様に表現できると思います。
① システム毎に手順が違う
サービスはシステムごとにカスタマイズ、あるいは個別開発します。基本的にはシステム毎、業界毎など、多種多様であり、やり取りの標準化は困難な状況です。セキュリティ対策もまちまちであり、DXが叫ばれる今でも、十分には統一されていないと認識しています。
② ログ情報の証拠能力が低い
トランザクションごとにデジタル署名を行うシステムは私は知りません。PKI方式を使って署名自体は可能ですが、秘密鍵が漏えいしてしまうと無力ですし、そもそも漏えいの検知が難しいので、十分な検査を行い状況証拠を整える必要があります。
③ 秘密の制御は難しい
トランザクションログ自体の署名がないので、確かな状況証拠を用意する必要があると説明しました。つまり、システム全体の情報を突き合わせて、矛盾がない事を証明しなければなりません。そのため、秘密にたいしても検査者のアクセスが必要となり、あらたな漏えいリスクを抱えてしまいます。
④ ユーザによる監査能力は無い
従来のトランザクションログの検証はサーバーサイドに一任する仕組みがほとんどです。クライアントアプリケーションにサーバーの検査のための情報を配布する様な仕組みはないと思います。結果、ユーザーが独立してサーバーの不正を正す事はできません。
AKIのトランザクションログ（分散ログ）
AKIは従来のトランザクションの課題を解決します！
AKIのおさらい
今まで説明してきたAKIの技術を簡単に振り返ります。
AKI Archiver
AKI Archiverをつかってデジタル署名ができます。
さらに、デジタル署名を作成する際に暗号化オプションを使って「秘密を取り除く」事ができます。AKI署名で暗号化する事を秘密を取り除くと表現しています。
公開前提の情報であれば改ざん防止という保証を、非公開としたいならば暗号化オプションが利用できます。
AKI TLS
そして、AKI TLSを使ってサーバーとクライアントをE2E（End to End）で接続し、セキュアなトランザクションを実現します。
クライアントとサーバーはAKI署名と情報とを、毎回、署名検証しながらトランザクションを交わします。
SureArchiver
SureArchiverはAKIの技術を組み合わせ、唯一性をもつアーカイブファイルを作成し管理します。
SureArchiverは多様な情報を取りまとめて唯一性を与えます。作成した情報は、デジタル世界において唯一であり、その管理はユーザー（作り手）にあります。
補足ですが、アーカイブに含まれる情報はユーザーのセキュリティ界面の外には一度もでないで取りまとめられる事も、大きな特徴です。クラウド型サービスは情報を預けている事を忘れてはなりません。もしもサーバー側で事故が起こったら取り戻しは不可能です。そのための対策はユーザーの責任であり煩雑な人の認証に集約されています。
分散ログ：割印
分散ログは、このアーカイブファイルに確かな証「割印」を提供します。なお、以降の説明ではAKI署名＋暗号オプションを例に説明いたします。AKI署名は本来は改ざん耐性が主目的でありゼロ知識暗号は付随機能です。本書では従来型トランザクションを例に取り、（情報の）秘密を排除する事に着目しています。ですので、混乱を避けるために、本来は付随機能であるゼロ知識認証による暗号を説明に盛り込んでいます。（情報に）秘密がなくても、AKI署名による改ざん耐性の優位性は揺るぎません。
AKIのトランザクションログ
AKIのトランザクションログを図にまとめました。
- AKI署名がトランザクションの中心にあり、情報が暗号オプションでパッケージされている事がわかります
- AKIの分散ログは「トランザクションログDB」と「割印ハッシュチェーンDB」の要素で構成されています
① AKI TLSによるサービス情報のカプセル化
AKI TLSでサービス情報をカプセル化する事で、秘密とトランザクションとを分離します。AKI署名としてメタライズされたトランザクションは、さまざまなITシステムに応用できます。
AKITLSは内容保証付きのE2E通信なので、ゼロトラストなインターネットでも安心してトランザクションが執り行えます。また、一般的なITシステムはリクエスト/リプライ型のメッセージ交換がほとんどなので、最小限のカスタマイズでAKI TLSが導入できます。
② ログ情報自体に証拠能力がある
トランザクションログにはAKI署名が記録されます。AKI署名だけでトランザクションの検証が独立して行う事が可能です。署名自体には秘密が含まれていないので、検証のためのセキュリティ維持コストを低く抑える事が可能です。秘密がない事を利用して、トランザクションログの公開検査なども可能となり、検証結果の共有コストも引き下げる効果が期待できます。
③ 秘密の制御が可能
トランザクションログ自体がAKI署名なので、全てのトランザクションは監査されています。さらに検査を突き詰めるため、システム全体の情報を突き合わせて全体に矛盾がない事を検証する事も可能です。
従来は、システム全体の監査を行うために、情報漏えいの防止などを配慮する必要がありました。しかし、分散ログは秘密が明確に隔離されているので、システム全体の検証においても漏えいリスクを低く見積もる事が可能です。
④ ユーザーに監査情報を預ける
トランザクションログの安全な共有のために、さらに「割印ハッシュテーブルDB」を提供します。クライアントアプリケーションにトランザクション完了の証として割印を配布する事で、クライアント主導での検査を可能とします。配布する割印は、情報自体は機密ではないので、配布することによる漏えいリスクはありません。クライアントたちが割印を持ち寄って、サーバーのトランザクションを検査する事も可能です。ユーザー主導でシステムを監査できる仕組みは、運用のセルフガバナンスを醸成し、エシカルなシステムを実現します。
分散ログの運用
SureArchiverを例に、分散ログの運用を説明します。
SureArchiverへの組み込み
SureArchiverは複数の情報をアーカイブし、SureArchiverファイルを生成しアクセス管理するウェブアプリケーションです。作成するSureArchiverファイルは高い改ざん耐性と、デジタル情報としての唯一性を提供します。この、改ざん耐性や唯一性をいつでも検証できる様に分散ログを組み込みます。分散ログを構成するトランザクションログDBと割印ハッシュテーブルDBを順に説明します。
トランザクションログDBについて
アプリケーションのトランザクション単位のやり取りを記録します。本書ではSureArchiverファイルへの処理が記録対象です。このトランザクションログは、SureArchiverファイルの作成や操作におけるトランザクションの検証結果そのものです。また、記録される情報はAKIDにリンクする複数の鍵が全て一致しないかぎり検証ができません。そして、情報へのデジタル証書も格納されているので非常に高い改ざん耐性をもっています。
割印ハッシュチェーンDBについて
トランザクションログDBは従来型ログと同じく、サーバーの運営者が維持管理するDBです。さらに、トランザクションログを証拠としてユーザーに配ることで、ユーザーを巻き込んだ健全な運用につなげます。ユーザーへの証拠の配り方は、トランザクションログという「券」に押印して「半券」としてもぎり渡すイメージがわかりやすいかと思います。もぎった半券を持ちよる事で認証するので、割印という表現を採用しました。
トランザクションログの構造
以下にトランザクションログDBの項目概要を示します。
| 項目 | 説明 |
|---|---|
| ログID | トランザクションログDBに登録時に付与されるインデックス情報 |
| 割印ID | 割印処理にて振り出されたインデックス情報 ・割印ハッシュテーブルDBの登録時のインデックス情報 |
| 記録時刻 | ログの記録時刻 |
| ログ情報 | AKI署名データ ・AKI TLSのリクエスト／リプライ情報 ・SureArchiverのデジタル保証書 |
| AKI TLSの作り手AKID | AKI TLSの作り手に振り出されたAKID |
| SureArchiverの相互押印AKID | SureArchiver作成に振り出されたAKID |
割印ハッシュチェーンの構造
以下に割印ハッシュテーブルDBの項目概要を示します。
| 項目 | 説明 |
|---|---|
| 割印ID | 割印ハッシュテーブルDBの登録時のインデックス情報 |
| 一つ前の割印ID | チェインされる一つ前の割印インデックス情報 |
| ハッシュチェーン・ノード | 一つ前の割印インデックスにあるハッシュ値、現分散ログ情報、そして記録時刻、を合成し算出したハッシュ値が格納されます |
割印ハッシュテーブルDBは「Rootノード」から連綿と続くハッシュチェーンを構成します。ハッシュチェーン・ノードには、直前のハッシュチェーン・ノードと現トランザクションログの分散ログ情報、そして記録時刻などをから算出したハッシュ値が格納され、一意の割印IDが振り出されます。サーバーはこの割印IDをトランザクションログDBに保存し、ユーザーは作成したSureArchiverファイルに格納されます。
アーカイブファイルさえあれば、ユーザーが承認さえすれば、秘密を公開しなくても整合性の検証ができます。この様な特性を持つデジタルチケットはSureArchiverの相互押印でないと実現は難しいのではないでしょうか。仮に作れたとしても、相応に複雑な手続きやデバイスが必要です。
ハッシュチェーンのRootノード
チェーンの検証を進めていくと、一つのノードに到着します。このノードをRootノードと呼んでいます。割印ハッシュチェーンDBのRootノードには、著者が所有している「NFT（Non-Fungible Token）」をハッシュ値計算用に使っています。
一番先頭の情報はSureArchiver以外で作りるしかないのでNFTを採用しました。NFTはブロックチェーンを利用してデジタル情報としての「唯一性」を提供する事ができます。正しい割印IDであれば必ずRootノードに到達します。もしも到達できない割印があれば、それは正常ではないトランザクションと断定できます。
NFT（Non-Fungible Token）
デジタル情報の唯一性をブロックチェーンで保証する仕組みです。SuerArchiverの割印ハッシュチェーンのRootノードのためにOpenSeaにNFTを用意しました。
AKIの前身はブロックチェーン技術を利用したPKI技術です。NFTは既に市場がありますので、知見をもっていらっしゃる方も多くいらっしゃるかと存じます。ブロックチェーンの知見からAKIを読み解いていただけると幸いに存じます。AKIは、ブロックチェーンの運用コストやコントロール特性などの課題を考慮して設計いたしました。
トランザクションログDBと割印ハッシュチェーンの関係図
以下に、トランザクションログDBと割印ハッシュチェーンDBの相関図をまとめます。
割印ハッシュチェーンのノードの接続数は1:nです。わかり易くするために単一ノードとしました。実装上はトランザクション負荷を考慮しAWS SQSやセッションごとのノード分岐などを盛り込んでいます。
分散ログの運用
サーバー（読み手）とユーザ（作り手）それぞれの視点での運用イメージを説明します。
運用イメージ
サーバー運営者（読み手）の運用
運用開始
SureArchiverの運用を開始するために、割印ハッシュチェーンDBのRootノード情報を登録します。唯一性が必要なのでNFTを採用しています。
運用中
SureArchiverファイルへのアクセスが起きるたび、トランザクションログDBと割印ハッシュチェーンに情報が追加されます。サービスを提供するユーザーには、「割印（割印ID）」を配布します。SureArchiverのクライアントアプリケーションは、受領した割印IDをアーカイブに格納します。
ユーザ（作り手）の運用
SureSrchiverの作り手は、読み手から送られてきたデジタル証書を使ってSureArchiverを完成させるだけです。完成したSureArciverには割印（割印ID）が改ざん耐性を確保した状態で格納されています。
第三者（持ち手）の運用
一つはトランザクションログの検証、一つは割印ハッシュチェーンの検証、そして割印の検証です。トランザクションログの検証と割印ハッシュチェーンの検証は運営者サイド（読み手）主体で行います。そして割印の検証には全てのユーザーが参加できます。
運用のデータフロー（まとめ）
処理のデータフローを図にまとめます。
- トランザクションをログDBにはAKI TLSと相互押印の認証情報しか記録されません
- 署名情報そのものが記録されているので単独で検証可能
- 割印は公開しても問題ない
- 割印から情報の類推やトランザクションログの捏造は不可能
ユーザーは割印が押された半券を所有するので、サーバーサイドに対する「証拠」を持ちます。そして、この証拠自体は割印を合わせる事しかできないので情報漏えいの心配はありません。ユーザーから半券を集めれば、統計的正当性からサーバーサイドの不正を正す事も可能です。
幸い、SureArchiverはファイルのアーカイブを行うシステムです。ですから、生成したアーカイブファイルにこの半券を格納しておく事もできます。たとえば権利証書の様な特別な資料に応用する事で改ざん抑止はもとより、運営側の不正までもは維持できる仕組みが構築できます。
分散ログの検証
サーバー（読み手）とユーザ（作り手）とのそれぞれの視点で利用イメージを説明します。
検証イメージ
サーバー運営者が検証する
サーバーでのトランザクションログの監査イメージは以下の通りです。
トランザクションログの監査
トランザクションログは検証用の鍵が添えられているので改ざん検証は即時に終える事ができます。クレンジング作業を行わなくとも直接トランザクションの検証が行える事が最大の特徴です。また、トランザクションログの内容自体がデジタル署名（＋暗号化）なので機密情報の漏えいリスクを最小限にできます。ログ情報の正当性確認において検証者にゼロトラストの概念が適応出来るのも新しいと考えています。
トランザクションログ＋割印ハッシュチェーンの監査
トランザクションログ自体の改ざん難度は非常に高いのですが、組織的な改ざんは論理的には可能です。組織的改ざんを検出のために「割印ハッシュチェーン」を監査します。
各トランザクションログには割印IDが格納されています。この割印IDの関連するハッシュチェーンのノードには連鎖する一つ前のノード情報と当該トランザクションのハッシュ値が格納されています。結果として、当該ドランザクションの正当性を確認した上で、割印IDをもとに割印ハッシュッチェーンの連鎖をチェックする事で、適切なトランザクションのつながりを検証する事ができます。最終的にRootにつながっていないハッシュチェーンを発見した場合、チェーンが途切れた時点がチェックポイントとして浮かび上がります。
この様なチェックポイントを検出できる仕組みを用意する事で、もしも組織的な改ざん活動が行われたとしても、チェックポイントを仕込む事で、大きな抑止効果が得られます。そもそも、AKIの様に、常に署名をしながら肝心の情報には唯一性が与え、さらにはそのやりとりがトランザクションに残される仕組みなので、このハッシュチェーンを用意するだけで、ほぼ組織的な改ざんは不可能です。情報認証における極めて限られた期間内での相互に交わされるデジタル認証と、署名鍵の明示的な再利用の禁止は、簡単で小コストで高性能な認証を提供します。
ユーザが検証する
ゼロトラストが前提であれば、逆説的にユーザー手動で検証することも可能です。先に説明した通りトランザクションログは署名＋暗号情報で構成されてるので、内容を知らなくても検証する事ができます。そして、ユーザーに検証プロセスを開示できるので「もやもや」が残りません。さらには、ユーザーの手元に割印IDという証拠の片割れがある事も、今までにない特徴です。割印IDを使い、公開されたトランザクションログを検証する事で、ユーザー側から健全な運営が行われた事を確認する事ができます。
第三者が検証する
もちろん第三者でも検証ができなければ、ゼロトラスト対応とは言えません。公開前提の情報であれば、意識する必要もなく第三者に渡して、気が済むまで検証してもらう事も可能です。暗号オプションが施されていたとしても、割印だけの利用で検証することは可能です。アクセス制御は作り手に残されているので、開示の可否はあくまでも利用者にあるのも重要なポイントです。
検証（まとめ）
以下、検証の効果を図にまとめました。
アーキテクチャレイヤ
分散ログのアーキテクチャレイヤは以下となります。
クライアントとサーバーの構成概要は以下のとおりです。
これで全ての概要を文書化しました。アーキテクチャのまとめを以下に書き出します。
- AKI ArchiverによるAKI署名（＋暗号オプション）
- ゼロ知識認証によるパスワードレス暗号
- AKI TLSによるE2Eなトランザクション
- トランザクション毎の検証を実現
- システム間のトランザクションをメタ化
- SureArchiverによる情報認証
- アーカイブファイル毎の唯一性の保証
- アーカイブファイル毎の永続的アクセス制御
- ゼロ知識認証によるパスワードレス暗号
- 分散ログによるエシカルな運用（セルフガバナンンスの醸成）
- トランザクションログの証拠能力を強化
- ユーザー自らが監査可能なシステム
まとめ
多くの技術要素を盛り込んで構成したAKIですが、分散ログにて全ての設計コンセプトについての説明は終わりです。できる限り図解してお伝えしたかったのですが、至らないところもいっぱい残ってしまいました。それでも、想像して、構築して、動作確認して、実際に確認できたことは、大変誇らしく思っています。本サイトを見ていただいて、興味を持っていただければと切に願います。
コンセプトや機能についての文書作成は終わりましたので、次回以降はユースケースについて踏み込んだ資料を記事にしていきたいと考えています。これから活性化するであろうWeb3.0時代の、使える暗号基盤として成長できる機会をつかめればと思います。自社商品への組み込みなどがございましたら、ぜひご連絡いただければと思います。引き続き、当サイトをよろしくお願いいたします。
PoCの積み残しについて
分散ログのSureArchiverファイルへの格納と検証は、予算などの調整の結果、未実装となってしまいました。次の開発の目星がついたら、割印の格納と収集、検査などについてもう一歩踏み込みたいです。分散ログに関する主要な特許出願は登録完了しています。
情報の安全な保存について
最後に一つだけ補足しておきたい技術があります。それは情報を分散して持ち合う事で改ざん耐性を確保する「ブロックチェーン」です。AKI自体も、ブロックチェーンを論理認証局として扱う発明を発展したものです。（商標がありますので製品名は控えます。私の名前で特許検索すれば確認できます。）
ブロックチェーンは既にセキュアな情報基盤として認知されています。しかしながら、システムとして大規模になりやすい特性は、情報を維持管理するという観点では扱いにくい面もあります。論理認証局の情報量であれば全然問題ない試算結果だったのですが、契約書や経理情報などはリスクの方が大きいと私は思っています。
そこで、ブロックチェーンの発想を180度切り替えて、データはあくまでもユーザーに持たせて一回だけの相互署名で唯一性を狙ったのがAKIの発想となっています。そして、ブロックチェーンと同様にハッシュチェーンで証拠だけを全体で共有する仕組みで、デジタルな証拠情報とする仕組みを用意して、AKIをブロックチェーンの安全性に近づける事ができたのではないかと考えています。
コメント