はじめに
クライアントとサーバーを結ぶデジタル署名とデジタルホットラインが整備できました。これらだけでも既存アプリケーションモデルで活用するには十分なユーティリティです。ですが、それだけでは「PKIと何が違うの？」という問いには答えられません。ブロックチェーン型暗号基盤の際にはそこまで踏み込めておらず、あくまでも信頼のガバナンスが前提であり、PKIの設計思想から抜け出せていませんでした。
AKIでは真の革新を目指しこの領域に踏み込んで行きます。もしも、組織的なガバナンスが得られなかったとしても、コンプライアンスが自動的に保たれる仕組みができれば、真のゼロトラストに対応できる暗号基盤の完成につながると確信しています。実現できれば、今主流の、不確かな成果に投資を続けるセキュリティ対策からの脱却が可能なはずです。本記事では、いよいよ非対称鍵の新たな使い方の提案に筆を進めていきます。
情報の認証を考える
AKI TLSではクライアントとサーバーをホットラインで接続し、通信ペイロードの新しいE2E通信を実現しました。双方が鍵ペアをあらかじめ知っている事で成立するシステムであり鍵ペアを使ったユーザー認証と言えます。本記事では、その認証されたクライアントが作る情報（さまざまなデータ）に視点を移します。この情報自体に個別に認証を与える事で情報自体の新しい使い方が提案できるのです。
Web3.0というバスワード
「情報認証」とは、データごとに個別に認証を与えアクセス制御できる様にしたものです。情報認証の必要性は今のインターネットにおいてもホットワードだと言えます。例えば「Web3.0」という言葉をちらほら聞く機会が増えてきていますので、この言葉を借りて説明します。
web3.0で提唱されている概念は主に分散型インターネットです。そこで着目されているのがブロックチェーンなのですが、技術的特性にばかり着目されていると感じています。運用での環境負荷やコストそして組織犯罪への対策など、新しい仕組ゆえに多くの課題が残っています。Web3.0のテーマを改めて考えてみると、「ユーザーの作り出した情報自体は作り出したユーザーにあるべき」というコンセプトであり、「情報へのアクセスコントロール」の必要性が望まれている事が読み取れます。AKIが掲げる「作り手/読み手/持ち手モデル」と「相互押印による情報認証」そして「情報認証のアクセスコントロール」とはまさしくWeb3.0が望むインターネットのあり方を、既存の技術基盤の上に作り出す事ができます。
PKIによる情報認証の課題
まず、PKIを使った情報認証を考えてみます。構造上は情報認証の作成者はサーバーですから、情報認証の利用者はユーザーです。本書のテーマでは書き手であるユーザーが情報認証を行うので、そもそもPKIでは不整合となる事は明白です。
- データ認証のために、クライアントごとに秘密鍵と公開鍵証明書を用意するのは現実的でない
- データごとに個別にデジタル証明書を発行するのは現実的でない
- 認証局を使って誰でも検証できる
PKIは今まで通りSSL/TLSに活用すべきです。
AKIによる情報認証
AKI TLSはユーザーごとに専用の鍵ペアを用意するので情報認証にはうまく適合できそうでした。しかし、そう簡単に事は運びません！PKIは公開鍵証明書を入手できればだれでも認証局を使って検証する事ができます。ところがAKIは認証局がないので、情報認証を行うための第三者の評価ができないのです…😱
- クライアントごとに署名鍵を用意できる
- データごとに鍵ペア（署名鍵と検証鍵）を用意できる
- 認証局に相当するアクターがいない
認証局がいなくても署名検証できる仕組みがないと活用の幅が広がりません！！そこで、AKI TLSユーザーであれば誰でも情報認証の署名を検証できる仕組みを、まず最初に整備します。それが「情報の作り手/読み手/持ち手モデル」です。
情報の”作り手/読み手/持ち手”モデル
アクセスコントロールを行うという事は、情報認証のターゲットとなる情報にライフサイクルが存在するという事です。つまり、情報認証は「作成」し「参照」され、「共有」し「終了（無効にする）」できる必要があります。そうすると作り手/読み手モデルだけではアクターが足らない事が明白です。ここで新たに「持ち手」というアクターを用意しました。各アクターの役割は以下のとおりです。
| アクター | 役割 |
|---|---|
| 作り手 | 情報認証（AKI署名を含む）を作成する人の総称です。作り手は情報認証を作ることが出来ます。利用する場合は持ち手としてアクセスします。情報認証のアクセスコントロールを行えます。 |
| 読み手 | 情報認証を検証する人の総称です。作り手に相対する存在です。作り手の情報認証作成時に相互押印サービスを提供します。作り手の指示に従い、情報認証へのアクセスコントロールを行います。 |
| 持ち手 | 情報認証を所有する人の総称です。読み手を介して情報認証のアクセス権を取得し読みます。 |
各アクターの相関を俯瞰すると以下のイメージになります。
相互押印による情報認証
情報認証のライフサイクルを実現するためには情報認証自体の独立性を確保する必要があります。ここでの独立性とは、情報認証がメディアやストレージに保存できる状態を指し示しています。そこで、デジタルならではの追加特性としてAKIでは「唯一性」を新たに考慮しました。まずは、この唯一性について説明します。
情報の唯一性
情報の唯一性とは、対象となる情報自体が完全に一致したとしても、情報認証された状態では必ず別の情報である事が判別できる事を示します。例えば、PKIのデジタル認証は秘密鍵を再利用する前提なので改ざん検知に活用できますが、これは一意性の検証です。唯一性の視点では、たとえ同じ値であったとしても情報認証を作成するごとに違う結果でなければなりませんし、異なった上で一意性を提供できなければなりません。では、なぜAKIは唯一性を作り出せるのでしょうか。その答えは鍵ペアの運用コストにあります。AKIは鍵ペアの運用コストを圧倒的に削減できます。その特性を利用し、常に新規の署名鍵を利用する事で唯一性を容易に実現できます。この単純な解決策をAKIの暗号基盤に組み込む事で情報認証の唯一性をつくり出しました。その仕組みが「相互押印」です。
デジタルな押印
旧来の人の承認モデル「ハンコで押印する」という認証の仕組みは、アナログですが実に分かり易く有益な手段です。そこで、このアナログな押印のプロセスをデジタル世界に持ち込んだ仕組みが「相互押印」です。作り手と読み手との間で「ハンコリレー」するイメージが分かり易いと思います。まず、デジタルな押印を定義します。非対称鍵の検証といえばデジタル署名です。デジタル署名との違いを示すことで押印とは何かを説明できると考えました。以下に比較表で表します。
基本的にはAKI署名の説明の延長ですが、大きな変化として「押印用の鍵は再使用しない」に着目してください。朱印をつけて印影を残す操作を、署名鍵を再利用できない状況にする事で実現したのがデジタルな押印です。いかに一度きり状態を検証できる様にするか創意工夫しました。
廃棄した事を証明するのは難しい
廃棄した事を証明する事は実はとんでもなく難しいです。もしも組織ぐるみで口裏を合わせられたら証明する事はとても難しいです。そこで、AKIは、鍵を廃棄を徹底させるのではなく、再利用が難しい状況に持ち込むアプローチを選択しました。再利用がとても難しいのであれば、結果として廃棄と同じ状況を作り出せます。再利用を抑止する方法は、およそ以下の手法が考えられます。
- 改ざんできない箱に検証鍵を預ける
- デジタル署名の機会を論理的に制限し再作成の難度を高める
「改ざんできない箱」は「ブロックチェーン」がそのまま当てはまります。ですが、AKIはブロックチェーン以外を使う宣言をしていますので、この方法以外を模索する必要があります。言い換えれば、十分な運用コストがあればブロックチェーンを採用する事でAKIは最強という事もできます。話が少し脱線しました。（汗）
改めて、再作成の難易度を高める施策「相互押印」について説明をします。
相互押印
デジタル署名の再作成を抑止するために、クライアントとサーバーとの関係性と同時性を利用した考え方が「相互押印」です。クライアントが署名したデジタル署名を、サーバーが即時に検証し追加署名する仕組みです。
情報認証の具体的な活用モデルとして「デジタル証書」を定義しました。上図のデジタル署名をAKI署名（AKI Archiver）で表現してみます。
押印が具体的にはどの様にAKI署名で落とし込まれたかが理解いただけたと思います。情報の真正性を担保として、作り手（クライアント）と読み手（サーバー）で同時に相互に署名している事が最大の特徴です。同時に相互署名することで署名用鍵の再利用を封殺する事が狙いです。
報認証の応用・デジタル証書
デジタル証書は対となる情報に関する保証書の役割を持ちます。作り手は認証したい情報に対して、このデジタル証明書を読み手の協力のもと作成し情報認証を終えます。作られた情報認証はAKI署名のゼロ知識認証を活用する事が出来るので、配布後のアクセスコントロールが可能となるのです。改ざん検知のみが目的であれば、デジタル証書は改ざんされていない保証書として活用できます。そして＋暗号オプションを使用すれば検証しないと内容にアクセスできないアーカイブとして活用できます。必ず情報にアクセスするために読み手のサービスを使う必然性が構築されるので、作成された情報認証は常にアクセスコントロールが必要な情報となり、これこそがブロックチェーンでも多分なしえられない真の分散インターネットのモデルに近づくはずです。
この様にして作成されたデジタル証書の再作成はとても難しいです。たとえクライアント側の署名鍵を入手できたとしても、相対するサーバー側の署名鍵を同時に入手する事はほぼ不可能です。しかもAKIDサービス自体は公開されていないので外部からの書き直しも、相応に高難度であると言えます。当然、ノーヒントで二つの鍵ペアの解析を行う事自体が十分に高難度である事は言うまでもありません。AKI Whitepaperで紹介した相互押印のシーケンス概要を以下に再掲載します。
それでは、この図にAKI署名の構造を重ねて単純化した図を掲載します。（AKI TLSの関係性は情報の作り手のみに省略）
情報そのものはデジタル保証書が完成するまでは作り手のセキュリティ境界の外に出ていません。これはセキュリティとして特筆すべきポイントです。情報認証が完了してからしか情報共有できないので「漏えいリスクが最小」な情報共有と言えます。そう、パスワードの漏えいの不安から常に監査し続けていた悪夢から解放されるのです！
それでも安心できない…
考えうる最後のリスク要素として大規模な組織ぐるみの改ざんがあります。しかしながら、この攻撃は改ざんにかかるコストがかかりすぎて、リスクに見合う効果が得られないと思われます。もちろんAKIは「分散ログ」をアーキテクチャに組み込む事で組織ガバナンスの自己醸成に結びつき組織犯罪の排除を図っています。続いては、相互押印で作られた情報認証をを利用したアクセスコントロールに関しての説明します。
情報認証のアクセスコントロール
デジタル保証書の検印の流れを確認するためにAKI Whitepaperのシーケンス概要を以下に再掲載します。
それでは、この図にAKI署名の構造を重ねて単純化します。（AKI TLSの関係性は情報の作り手のみに省略）
情報認証の検証についても情報自体の交換は行っていません。情報の作り手は読み手に任意のアクセスコントロールを指示する事で自由にアクセスコントロールを行う事ができます。論理的に唯一性を持った情報でさらにゼロ知識認証を採用しているので、どれだけコピーされ共有されようとも認証する際は必ず読み手に問い合わせなければならないからです。作り手が終了と宣言した時点で、どれだけ拡散していても一瞬で無効にできます。検証においても強力なセキュリティ特性を提供します。持ち手自体はAKI TLSにて個人認証が行われているので、基本的には情報認証へのアクセスは必ず証拠特性付きで記録される仕組みです。すなわち、利用者トレーサビリティにおいても優れた特性を提供します。
相互押印のアーキテクチャレイヤ
相互押印アーキテクチャのレイヤ構成は以下の通りです。
システムへの組み入れ
作り手/読み手/持ち手モデルに相互押印アーキテクチャを組み込んでみます。
これでAKIの非対称鍵暗号の要が全て設計完了しました！いよいよIT環境に実装して、システムとして構築し実証実験を行うだけです！！
まとめ
Web3.0等、次世代の分散インターネットで要望されている、ユーザー主体で永続的な管理が可能な情報に対する一つの解答策が用意できました。具体的なIT基盤にPoC（試験実装）を行い実証するフェーズへと移行します。IT環境にAWSを採用し、既存のフレームワークにAKIアーキテクチャ実装した成果をご紹介していきます。
開発するアプリケーションはWebアプリといたしました。インストールが不要でAKIのアーキテクチャを評価できる事を目的としたからです。既存のITアプリケーション開発とどの様に折り合いつけたのか解説できれば、AKIの可能性をご評価いただけるのではないでしょうか。
引き続き、本サイトにお付き合い頂ければ幸いです。「SureArchiver」の解説記事をご期待ください！
CryptBoard.io
面白い記事を見つけましたのでご紹介します。クリップボードにPKIを組み込んでゼロ知識証明で情報共有する試みです。情報提供者主体で安全な情報共有をしたいというのは誰しも望んでいるのだと思えて、また、頑張る気になりました！
もう一歩踏み込んで、共有した後も適切にコントロールできるのがSureArchiverなんです。いつか記事として取り上げられる様、情報発信に努めてまいります！！
コメント