はじめに
私はブロックチェーンの堅固な特性に着目し、公開鍵証明書を使わない新しい仕組みの暗号基盤を考案しました。ブロックチェーンが提供する強力な改ざん耐性は第三者の与信を不要とする事ができます。この特性を利用する事でインデクス情報自体にPKIの「組織認証相当の公開鍵証明書」相当の品質を提供できます。以下にブロックチェーンによる公開鍵暗号基盤の構成概要図を示します。
資料からも分かる通り基本構造はPKIと変わりません。ブロックチェーンの高い改ざん耐性を「組織認証」相当の論理的保証に利用するシステムとして、組織認証を必要とする情報システムには問題なく受け入れていただけました。
次のチャレンジとして、ブロックチェーンほどの高い性能を要求しない領域にマッチする暗号基盤の創出としました。もっとカジュアルに利用できる仕組みを用意できれば、一気にセキュリティのあり方を革新できるチャンスになると考えたからです。そこで「作り手/読み手モデル」というソフトウェアアーキテクチャモデルを規定しました。まずはアーキテクチャモデルの説明をいたします。
情報の”作り手/読み手”モデルとは
AKIが提唱するソフトウェアアーキテクチャモデルです。ソフトウェアアーキテクチャモデルとは、クライアントサーバーモデルや分散コンピューティングなど、システムの組織や構造を説明するためのものです。
クライアント/サーバーモデル
伝統的なソフトウェアアーキテクチャモデルと言えばクライアント/サーバーモデルが挙げられます。ネットワークに参加する機器にサーバーとクライアントという役割を与えたアーキテクチャです。 セキュリティ視点では、認証局が公開鍵証明書の与信を提供するサーバーとして参加しています。
”作り手/読み手”モデル
ネットワークのやり取りに着目して役割を再定義を試みました。シンプルに通信のやり取りをみてみると、およそ以下のやり取りとなります。
- クライアントからサーバーへのリクエストの送信
- サーバーがリクエストを受信
- サーバーからクライアントへサーバーレスポンスの送信
- クライアントがサーバーレスポンスを受信
そこで、データの送信サイドを「情報の作り手」、サーバーの受信サイドを「情報の読み手」と定義すると、リクエストにおいてはクライアントが作り手、サーバーが読み手となり、レスポンスでは逆の関係としてまとめる事ができます。この関係性に非対称鍵の鍵セットを重ねると以下のルールが定義できます。
- 情報の作り手が「作り手鍵（署名鍵）」で署名（＋暗号）して、情報の読み手が「読み手鍵（検証鍵）」で検証する
このシンプルなルールを、従来型アプリケーションモデルに適応してみます。
非常にシンプルにまとめる事ができました。クライアントとサーバーとはお互いに鍵を持ち合うことを与信としているので、第三者の与信が不要となっている点に注目してください。
- 情報の作り手はクライアント、読み手はサーバー
リクエスト・レルポンスの視点では、それぞれ作り手と読み手が入れ替わる - メッセージのやり取りの相互に専用の非対称鍵を使ってゼロ知識証明でやり取りする
- 通信時に鍵交換は行わないので鍵漏洩のリスクはほぼゼロ
- 常に署名付きメッセージで情報交換するという特徴
常に署名付きメッセージでの情報交換というのは非常に画期的です。常に検査が可能な情報交換は、ゼロトラストなシステム構築の実現可能性を推し進める事ができます。さらに、既存アプリケーションへの組み込みに成功する事で、既存ITにも最小の修正で適応できる可能性を秘めていました。AKIのPoC（Proof of Concept：実証実験）では、AWSプラットフォームにて問題なく適応できる事を確認しました。
新しいソフトウェアアーキテクチャモデルの説明は以上です。このソフトウェアアーキテクチャを念頭に置いてAKIの基礎となるAKIDサービスの具体化を練っていきました。
AKIDサービスのアーキテクチャレイヤ
AKIDサービスのアーキテクチャレイヤは以下の通りです。
AKI Coreライブラリ
AKIの中核を成す暗号ライブラリです。非対称鍵暗号および共通鍵暗号をAKIで利用できる様にラッピングしています。
AKIDサービス
検証用の鍵を格納管理するサービスです。AKID自体は単なるデータストアなので、従来のITシステムと変わりはありません。
AKIDが提供する主なサービスは以下の２点です。
- 検証鍵を登録（複数の登録が可能）しインデックス情報「AKID」を振り出す
- AKIDに対応した検証用鍵を取り出す
システムへの組み入れ
作り手/読み手モデルへAKIDサービスを組み込んでみます。
作り手/読み手モデルのRSA暗号による最適化
AKIDサービスの配置を説明するにあたりRSA暗号を前提として進めます。RSA暗号は「作り手鍵で署名→読み手鍵で検証」「読み手鍵で暗号→作り手鍵で復号」が成立する双方向特性を持っているため、リクエストとレスポンスが一つの鍵ペアで済み、情報の作り手と読み手に集中して説明する事ができます。もちろんRSA暗号以外の最新の非対称鍵暗号を取り入れられるよう配慮していますので、ご安心ください。この辺はほんとうに大変なんですよ説明が・・・(^^; 先の図をRSA暗号で再整理するとさらにシンプルになりました！！
クライアントとサーバーとで鍵を持ち合う仕組みについては「鍵を持ち歩こう！・KeyCase」をご参考ください。
AKIDサービスの配置
情報の検証は読み手鍵で行います。つまりAKIDサービスは情報の読み手側にあるべきです。クライアント/サーバー形式でもサーバーにサービスを配置するのが一般的なので好都合です。とても重要なポイントとしてクライアントごとに専用の鍵ペアが用意できる事が挙げられます。PKI方式ではクライアントにて公開鍵証明書を使って共通鍵をサーバーに渡す事でセキュア通信を確立していました。これは公開鍵証明書の与信を認証局が行う仕組みだからです。AKIは鍵ペアが成立している前提なので専用の鍵ペアを使ってE2E(End to End)セキュア通信が実現します。先の概要図に情報の作り手/読み手視点で鍵ペアを配置してみた図は以下のとおりです。
以上、AKIDサービス自体は非常に単純です。しかし、ブロックチェーンの様な対改ざん特性も持っていないので、このままではセキュリティ特性はゼロです。検証用読み手鍵の格納サービスにすぎません。これらの課題は、上位のアーキテクチャレイヤで対策を講じてセキュリティの完成度を高めていきます。AKIDサービス自体は、AKID（一意なインデクス）と検証鍵を保存する仕組みと理解していただければ十分です。普通のデータストアの機構を利用できるので、非常に柔軟な運用設計が可能です。
AKIDの仕様
AKIDはAKIDに読み手鍵（束）を格納した際に発行される一意なインデックス情報です。
- 読み手鍵（束）登録時にAKIDを降り出します
- AKIDの情報は更新はできません。削除のみ可能です
- 分散ログシステムの記録で正当性検証が可能です
- 検証ができないAKIDは不正と判断します
読み手鍵を束として登録する事で改ざん難度を高めるアプローチです。相互押印やクライアントへの署名鍵振り出しなどで活用しています。単純ではありますが、改ざん防止の観点では非常に効果がある方法です。システムでは排除が難しい組織的悪意に対して論理的に排除できる特効薬になっています。アーキテクチャの配置図は以下の様にまとめる事ができます。
まとめ
以上がAKIDサービスの概要です。概要図として取りまとめると以下の様になります。
クライアントごとに個別に署名/検証が行える状況となりました。続いては、AKIの肝ともいえるAKI Archiverレイアの説明です。複数のデータを情報として取りまとめ署名（＋暗号）するのでアーカイバと読んでいます。（PKIの署名とも区分するためでもあります。）アーカイバ機能をうまく設計し情報を効率的にまとめる事ができれば、結構ハッピーな情報流通を実現できるかもしれません。
コメント