はじめに
いよいよ一つのアプリケーションとして形にします。新しい暗号基盤で作り上げるのですから、今までにない新しいコンセプトを盛り込んだツールにしたいと考えました。文字通り「トラスト レス（Trustlessness：第三者による保証がない）」な環境にさらされても問題ないアーカイブシステムの提供を目指しました。結果、どんなに拡散してもアクセス制御が可能なWeb3.0時代にふさわしい分散指向アーカイバが完成したと自負しています。AKIをどのようにアプリケーションに取りまとめたのかを本記事で解説いたします。
Web3.0について
本サイトを構築している際によく耳にする様になったバズワードに「Web3.0」があります。ブロックチェーン技術に代表される「分散型のインターネット」を指向する新しいネットワークの事だと理解しています。情報の認証・相互押印と持ち手モデルでも触れましたが「ユーザーの作り出した情報自体は、作り出したユーザーにあるべき」というコンセプトが根幹にり、方向性を整理すると以下の特徴が挙げられています。
- 分散化
- 透明性
- 所有権
- インセンティブ
これはAKIが実現したい事そのものです。私の力量では言葉が足らずうまく説明できなかったのですが、識者の方々がうまく表現してくれてとてもありがたいです。少なくとも、技術的先行者が同じ指向性で変革を進めている事実を認識できましたし、その最先端を成し得た事がとても嬉しく思っています。😄まずはSureArchiverのアプリケーション概要を紹介した後にWeb3.0コンセプトとの対比を示します。
アーカイバのファイル構造を設計
まずはアーカイバの基本的な構造を取り決めます。アーカイバファイルの構造は非常に単純です。相互押印で作成したデジタル証書と情報を一つにまとめるだけです。
SureArchverサービスのデモ動画
SureArchver Webアプリケーションのデモ動画です。AKIの実証実験として必要な機能一式をWebアプリケーションとして取りまとめています。
相互押印のアプリケーション最適化
SureArchiverはウェブアプリケーションサービスとして提供します。そこで、作り手/持ち手の視点で検討し相互押印の情報最適化を行いました。まず相互押印の基本フォーマットを再度説明します。（暗号化オプションは割愛します）
ウェブアプリケーションを構築するにあたり、AKI TLSの作り手署名（ペイロードを流れる署名）を相互押印と連携します。相互押印の特性を生かしつつアプリケーション仕様を織り込んで利便性とセキュリティの強化を狙います。AKI TLSとの連携を組み入れたデジタル証書のイメージは以下のとおりです。
補足ですが暗号化オプションは以下のイメージです。ゼロ知識認証を使って共通鍵暗号による暗号/復号が情報に施されます。
SureArchiverで作成したアーカイブファイルには３つの鍵がリンクしています。
- 相互押印/作り手が作成したAKI署名（作り手）の検証鍵
- 相互押印/作り手が作成したAKI署名（作り手）の検証鍵
- AKI TLS/作り手のユーザー検証鍵
一つのAKIDに３つの鍵をリンクする事で改ざん難度はさらに向上します。またユーザー専用署名鍵で情報のAKI署名を別途取得してアーカイバとリンクして保存する事で情報資源の蓄積を狙えます。AKI署名情報自体は非可逆な情報なので漏えい事故などに神経をすり減らす事もなります。SureArchiverサービスで実現が可能な商材についても別途記事を作成予定です。
アーカイブのフォーマット
アプリケーションに合わせた相互押印の仕様は決まりました。あとは実際のアーカイブコンテナフォーマットを決める必要があります。アーカイブコンテナフォーマット自体は、アプリケーションの特性で変わるものなのでAKIでは規定しない方針です。例えばPDFコンテナの様なアプリケーション依存フォーマットでも利用できる仕組みであるべきだからです。最初の実装ではコンテナフォーマットにtar形式を採用しました。
以下に生成されるアーカイブファイルのファイルフォーマットを示します。
アーカイブの作成
アーカイブファイル作成は以下のステップで設計しました。
- Webブラウザに会員ログイン
- 既存ITのログイン認証と連携する（完全なパスワードレスを実現！）
- ローカルPCのファイルを指定してアーカイブする
- アクセス制御を設定できる
- アーカイブ対象のファイルはサーバーに送らない
- 大容量ファイルのアーカイブも可能とする
- ローカルPCにアーカイブファイルが作成される
非常にシンプルですね。このコンセプトで画面を設計しました。
アーカイブの展開
アーカイブファイルの展開は以下のステップで設計しました。
- Webブラウザに会員ログイン
- 既存ITのログイン認証と連携する
- ローカルPCのアーカイバを指定して解凍する
- 検証と解凍の選択ができる
- 作り手のアクセス制御に従う
- 作り手に解凍許可の申請が行える
- ローカルPCにファイルが展開される
こちらも非常にシンプルですね。それでは、いよいよアプリケーションの開発の準備に入ります。
UI等のデザイン
UI設計に使用したツールは「Justinmind」です。非常に使いやすいツールでした思ったイメージでサクサク設計できて、SIerとの共同作業も効率よく進行できました。
しかしながら、やりたい事全てを盛り込めませんでしたけどね。こういったイノベーティブな事を第三者に説明しながら開発するのは本当に難しいですね。改めて痛感しました。ぜひ予算を確保して完全実装を成したいです！
画面設計なんて本当に久しぶりでした！こんな便利なツールを使って設計できるなんて、なんて良い時代なんでしょう。新人気分で楽しく作る事ができました。
「Draw.io」を使ってUI構造を共有しました。ブラウザーだけで完結して使える素晴らしい作図ツールでした！こちらも参考として作成物を掲載します。
UMLで設計
要求仕様や機能設計は「astah* professional」を使ってUMLで行いました。SIerがぜひこれで進めたいとの申し出もあり、モデリング言語で抽象化できれば混乱も少なかろうとの考えで採用しました。モデリング言語支援ツールとして機能は必要十分です。
全くの私見で恐縮ですが、久しぶりに使ってみて「ライセンス管理」には課題があるかなと感じました。自前でサーバーを立てるのも面倒でしたし、作業パソコンへのライセンスの持ち出しも逐一面倒です。もちろん、顧客によっては排他的ネットワークが前提になる事はよくあるのでこの仕様なのも理解はできます。企業人であれば問題はないですが、働き方の多様化が進む中ではもう一歩踏み込んだ利便性は必要ではないかと思います。視点を変え一つのアプリケーションライセンスの実事例とすると、今回の活用で知見という大きなメリットを享受できたとも思えます。今回のアーカイバファイルはDRM的活用ができるので、こういった事例への応用が一考できます。ぜひ記事として書き上げたいです。
さて、ツールを駆使してアプリケーション設計をなんとか終える事ができました！いよいよ詳細開発をスタートします。😄
IT技術の選別
詳細開発にあたり必要なIT技術を選出します。できる限り既存のITサービスを利用する事でAKIの実現可能性を高めます。
ITプラットフォーム
SureArchiverのプラットフォームには「Amazon Web Service」を選択しました。AWSは今更説明する必要もありません。私もAWSのSolutions Architect（Associate）資格を所有していたこともあり、なじみがあったからです。このブログもAWS上で構築しています。AWSにはさまざまなサービスが提供されています。本記事では特に要のポジションとなったサービスについて抜粋して紹介します。
AKI Core Library
AKIの中核となるライブラリです。記述言語は「Go言語」です。初版ではRSA暗号を採用しています。
AWS Lambda
サーバーレスでイベント駆動型のコンピューティングサービスです。サーバーレスってなに？とも思うのですが、要はプログラムコードをイベントで駆動するサービスです。頭では理解していたのですが、いざ開発してみると、なるほどと思うことばかりでした。プロビジョニングが不要、そもそもサーバーがないから起動も停止もないというシステムはとても新鮮です。この環境に「AKI TLS」を実装し「AKI Archiver」が想定通りに機能できれば、それこそWeb3.0時代のさまざまなソリューションにAKIが活用できる確証たりえます。
Amazon Cognito
「AKI TLS」の実装において、「人の認証」をどう考えるべきかが大きな課題でした。また人の認証は日進月歩で技術革新が進んでいる分野なので、AKIはその技術を活用する道を選択します。
そこで人の認証はAmazon Cognitoを採用しました。Amazon Cognitoの人認証の仕組みにAKIDサービスを組み込み、認証したユーザー専用の署名鍵を配布する仕様としました。AKIではこのユーザーアクティベーションの仕組みを「KeyCase」と呼んでいます。
AWS CloudFormation
SureArchiver開発とは直接関係しませんがAWSのDevOps環境として今回のナレッジ蓄積に活用しました。アプリケーション自体はサーバーレスでゼロプロビジョニングですが、開発環境はそうはいきません。AWSの多様なサービスをプロビジョニングして構築する必要があり、相当に大変な作業です。CloudFormationを作り込んでおく事でAWS構築のさまざまな知見を情報として残し継続する事ができます。
プロビジョニングを作り込む事は、思った以上に運用ノウハウを資産に変える効果がありました。残念ながらOpsサイド（テストの自動実行）は今回はコストが足らず作り込めませんでした。次回はOpsサイドも充実してAWSのDevOpsの神髄を体感したいと思います。😄
React.js：UI構築
UIプラットフォームには、React.JS（JavaScriptライブラリ）を採用しました。今回のSIerのおすすめということで採用しました。私が作成したUIをうまく落とし込んでくれたと思います。
Webアセンブリ
Go言語で開発したAKI Core Libraryは、サーバーとクライアントの双方で稼働させる必要があります。今回のPoCでは開発生産性を高めるために「WebアセンブリによるGo言語→JavaScript変換」を採用しました。これでコアライブラリの開発にリソースが集中できます。先の「AWS CloudFormation」と組み合わせる事でDevOpsのDevパートも捗ります。
使用したAWSを俯瞰する
SureArchiverを構成するAWSサービスを俯瞰した図を示します。
AWSはオーソドックスなシステムです。Webアッセンブリによる暗号処理のパフォーマンスも想定範囲に収まったのは非常にラッキーでした。普通にアプリケーションとして成立するパフォーマンスが得られました。
SureArchiver・Webアプリケーション
SureArchiverの具体的な操作ついては操作マニュアルを用意いたしました。また、簡単ですがアーカイブファイル作成の過程を動画にしていますので併せて機会があれば見ていただければ幸いです。
詳細はこれらの記事にまかせて、本書では肝となる機能を抜粋して解説いたします。
アーカイバの作成
ローカルの特定フォルダーを一括でアーカイブする事ができます。ウェブアプリケーションですのでインストールしなくても利用する事ができます。また、KeyCaseを導入する事で複数の端末で利用する事も可能です。
「入力フォルダー」にあるファイル群をアーカイブし、「出力フォルダー」に「アーカイブファイル名」で保存します。アーカイブの際に対象となるファイルはSureArchiverサービスへ送付されることはありません。ですので漏えいなどを心配せずに安心してアーカイブする事ができます。作成したアーカイブファイルはタイムスタンプ相当の処理が施され唯一無二の情報である事を保証できます。
アクセス制御の設定
アーカイブファイルには様々な設定が可能です。マニュアルより機能説明を抜粋します。
| 機能 | 説明 |
|---|---|
| 暗号化 | 本実装では暗号化のみとなっています。 SureArchiverはタイムスタンプ等唯一性の提供が主体です。 暗号化されていない開かれたアーカイブにする事で様々な活用が想定できます。 |
| 開示リクエスト自動承認 | アーカイブファイルの持ち手がファイルを展開する際に、アーカイブファイルのオーナー承認を自動で行うオプションです。 アーカイブファイルへのアクセスがトレーサビリティ情報として取得されます。 |
| 展開可能期間 開始日 | アーカイブファイルが展開可能となる日を設定します。 |
| 展開可能期間 開始日 | アーカイブファイルが展開終了となる日を設定します。 |
| 展開可能人数 | アーカイブファイルの展開な人数を設定します。 |
| 展開可能回数 | アーカイブファイルの展開な回数を設定します。 |
改めてご想像ください。今までのアーカイバは配布された以降の管理は行えませんでした。サーバー側でのアクセス管理自体は他の事例もありますが、あくまでもサーバー側の管理で実現しています。
対してSureArchiverは配布後もアクセス制御は作り手に残ります。作成アーカイブそのものに唯一性を持たせ、サーバーはその検証用の情報しか持っていません。結果、アーカイブのアクセス権制御はあくまでもユーザー（作り手）にある事こそが肝なのです。どれだけ拡散されコピーされようが作り手がアクセス制御を行えば瞬時に、すべてのアーカイブに適応されます。シンプルに唯一なアーカイブファイルの検証鍵セットは、ユーザー（作り手）しか利用できないから実現できる仕組みなのです。さらには、AKI TLSが利用前提なので従来にはない高いトレーサビリティが提供できる事も大きな特徴です。
アーカイバの展開
SureArchiverにて作成されたアーカイブファイルを展開します。「入力フォルダー」にあるアーカイブファイル群を検査/展開し「展開検査一覧」に検査結果を表示します。「改ざん検査のみ」のチェックがなければ、「出力フォルダー」にファイルが展開されます。
展開検査一覧と開示リクエスト
開示リクエストが未承認なアーカイブファイルは「結果」に「未」と表示されます。承認済なアーカイブファイルは「結果」に「〇」が表示されます。
「未」なアーカイブファイルを選択し「承認リクエスト」を押下する事で、対象となるアーカイブファイルのオーナーに「開示リクエスト」をメールします。アーカイブファイルのオーナーが承認したら「アーカイブ開示リクエスト承認」メールが届き、アクセスが許可された事を知る事ができます。拡散されたアーカイブファイルの解凍依頼が届いているのです。実際に動かしてみるとなかなか面白い機構です。😄
既存技術との比較
既存のアーカイバツールやクラウドストレージと機能的比較を行いました。あくまでも簡易的な比較で恐縮ですが本質的な間違いはないと思っています。今後の記事で応用ユースケースを提案して行きたいと思います。
| 機能 | ZIP、LHA、他 | クラウドストレージ | SureArchiver |
|---|---|---|---|
| 暗号機能 | パスフレーズ入力 | 運用対応 ・ストレージを暗号化 ・持出し時にZIP化 | パスフレーズは自動 ・ユーザーには知らされない |
| 復号機能 | パスフレーズ入力 | 対応外 | AKI署名の検証OKにて自動復号 |
| 改ざん検知 | なし | 運用で保証 | あり |
| タイムスタンプ機能 | なし | 運用で保証 | あり |
| 無効化 | なし | アクセス制御で対応 ・情報自体の無制御 | あり ・検証を強制的にNGに設定可能 ・暗号済みの場合は復号NGを設定可能 |
| 複製、分散 | 対応外 | 対応外 | 唯一性の元でアクセス制御可能 ・持ち手が必ず認証する仕様の為、制御可能 |
| 大容量ファイルの処理 | 可能 | 可能 | 可能 |
SureArchiverのアーキテクチャレイヤ
完成したSureArchiverのアーキテクチャレイヤは以下となります。
クライアントとサーバーの構成概要は以下のとおりです。
SureArchiverアプリケーションを使って「情報認証」による配布後のアクセスコントロールを具体化しました！これでSureArchiverアーカイブファイルのフォーマットが確定します。このアーカイブファイルを利用して、改めてSureArchiverにAKI TLSを組み込んでSureArchiverの完全な完成を目指します！
Amazon CognitoとKeyCaseの連携
SureArchiverの基礎コンセプトはPoC検証が完了しました。人の認証との連携モデルを明確にしトラスト レス対応の道筋を完成させます。再帰的ですが、この最後のテーマのためにSureArchiverの機能を拡張してKeyCaseを開発します。いよいよ次回の記事で、当初想定していた分散指向アーカイバのウェブアプリケーションが完成します。
まとめ
SureArchiverを構成する技術要素の説明は以上です。次の記事ではAmazon cognitoとKeyCaseを使ってAWSの認証とAKI TLSとの連携を解説します。
Web3.0について
「はじめに」で触れたWeb3.0に対するSureArchiverの特徴をまとめます。最大のポイントはコンセプトだけではなく、具体的に稼働するシステムが存在する事です。ブロックチェーン以外でのWeb3.0構築の基盤となればなぁと思っています。ぜひSureArchiverをお知りおきください、どうぞよろしくお願いいたします。
テータの分散化
AKIは情報の唯一性を確保する事で、分散しても情報の信頼を成立する仕組みです。
また情報のアクセスコントロールは作り手に委ねられるので、サーバー主体の情報管理は不要です。
情報そのものをトラスト レスな環境で安全に取り扱う事は、従来の過剰とも言えるコンテナシステムへのセキュリティの制約を取り外す事が可能です。安価なUSBメモリやDVDなどといったセキュリティ性能で敬遠されていたメディアも復権することも容易に想像できます。ビックテックに独占されてしまったインターネットですが、また、消費者にフリーで開かれたインターネットとして取り戻せないかなぁ…なったらいいなーと記事を書きながら思う毎日です。少なくとも、USBメモリをうっかり無くしても「安心して枕を高くして眠れる」って最高ですよね。
アーカイブの透明性
相互押印では２重の、そして、SureArchiverでは３重の鍵セットによる論理的な認証が施されています。さらには分散ログによる証拠の分散にて、組織的改ざんの可能性を排除します。これらは、特定の人や組織などを頼らずとも自然醸成されるシステムとしてデザインしており、「トラスト レス」を施行し、システムが自動でデータを検証し透明性を得る事ができます。透明性によって誰もがデータを検証し真実を得る事ができるのです。
分散して台帳を持ち合う事で透明性を確保するブロックチェーンに対し、相互押印しながら証拠（ログ）持ち合う事で透明性を確保するのがAKIの特徴です。
アーカイブの所有権
作り手（ユーザー）が作成したデジタルコンテンツの所有権やコントロール権はあくまでも作り手にあります。そして作り手が創出した価値を分配する持ち手（ユーザー）を、作り手自身が選んで、契約を締結することができるのが最も特別です。SureArchiverに格納されたデジタルコンテンツは単なるデータではなく、作り手が所有権を持つデジタル資産です。これはWeb3.0における、スマートなウェブに適応できる全く新しいインターネットの技術になり得るかもしれません。このブログを見ていただいて興味が湧いてきましたら、ぜひコンタクトをください！！
インセンティブ
経済圏の形成は、それこそ門外漢なので深掘りしていません。
しかしながら、ブロックチェーンと同様にインセンティブを形成できる可能性はあります。
将来、しかるべき暗号経済の専門家の目に留まり検討頂ければその可能性自体はゼロではないと考えています。
ブロックチェーンは運用視点で課題が大きいのでAKIの様な分散手段も十分にニーズがあると考えています。
私如きに暗号経済を語るだけの知識はないのでほぼ妄想ですが…もしかしたらはありえそうです。(^^)/
次の記事はSureArchiverをカスタマイズして作成したウェブアプリケーション「KeyCase」です。
コメント