はじめに
「トラスト レス（Trustlessness：第三者による保証がない）」に対応するアーカイバ「SureArchiver」を開発しました。このSureArchiverの最初のアプリケーションに応用した事例が「KeyCase」です。自分自身をカスタマイズして組み込む入れ子構造となり、非常に分かり難いお話になってしまいます。ごめんなさい。（汗
とりあえずまぁ、SureArchiverがトラスト レスに対応できる仕組みなのは間違いありません。だからこそ、KeyCaseとして専用鍵の安全なコンテナシステムとしてカスタマイズします。KeyCaseをSureArchiverウェブアプリケーションに組み込む事でシステムとして完成させます。
カスタマイズの概要
KeyCaseはSureArchiverの情報認証の暗号オプションをカスタマイズしたものだと説明しました。以下に、カスタマイズの概要を図にまとめます。
KeyCaseはユーザーに割り当てられた専用鍵（PKIにおける秘密鍵相当）を情報認証で暗号化したアーカイブファイルです。ユーザー認証と連携し認証と同時にゼロ知識認証する事で、安全にユーザーの専用鍵を取得できます。非対称鍵暗号を採用しているので対タンパ領域などの特殊なセキュリティメモリなどは必要ではありません。認証情報はクライアントとサービスそれぞれで分散して認証し合うため、簡単な仕組みながらも高い改ざん耐性を持っているからです。
では、なぜSureArchiverのカスタマイズが必要だったのでしょうか。それは、KeyCase自体はAKI TLSが使えない前提で動かす必要があったからです。ですからKeyCaseは通常のSSL通信の上で情報認証を使います。KeyCaseはユーザー認証に連動してサインイン時にのみ情報認証を行う様に設計しました。KeyCaseの認証が成功すれば専用鍵が入手できるので、それ以降をSSLからAKI TLSへ引き継げます。特筆すべきは、AKI TLS成立まで専用鍵の交換が一切行われていない事です。さらにAKI TLS自体が都度署名しながらの情報交換を行うため、高いトレーサビリティも提供します。
Amazon CognitoとKeyCaseの連携の概要は以下の通りです。
- サインイン
- KeyCaseの生成
- KeyCaseの情報認証を行う
- 認証に成功
- KeyCaseの検証用の鍵を送付
- KeyCaseがゼロ知識認証され、専用鍵を取得
- AKI TKS（クライアントサイド）に設定
- 相対する専用鍵の片割れを取得
- AKI TLS（サーバーサイド）に設定
- SureArchiverサービスを開始
Amazon Cognito（ユーザー認証）とKeyCase（情報認証）がシームレスに連携しAKIアーキテクチャの基盤整備を行います。AKI TLSが確立すれば「パスワードは知らされないけど適切に処置された」安全なアーカイブファイルを自由に作成できます。これで、ネットもUSBメモリもDVDも使い倒せます。😄
ユーザー認証と情報認証について
詳細説明に入る前に、今一度ユーザー認証と「情報認証」に関して再確認しておきます。
情報認証は本サイトでの造語ですので、混乱しないためにも、今一度説明の機会をいただきます。
ユーザー認証
ユーザーの認証は日々進化しているので、これら新技術をいち早く採用して活用する事が最善策です。AKIはユーザー認証と共存するものであり、排他をするものではありません。今後は、多様なユーザー認証とのマッシュアップ事例を積み上げて行ければと考えています。
そもそも、個人認証はグローバルを指向する事が望ましいと私は考えています。いつでも、どこにいても、どんなプラットフォームを使っていても、安全に認証できれば、とっても素晴らしいデジタルライフを送れる事でしょう。もちろんそういった未来を見据えてGAFAや通信キャリアを中心に技術革新が進められている事は今更言うまでもないです。例えば、スマホを使った所有認証などは、誰もが既に経験済みではないかと思います。
私はドコモを使っていますが、モバイルを使った所有認証が既に導入されています。（使いやすいかどうかはアレですが、少なくともモバイル回線を使ったパスワード レス認証の事例です）マイナンバーカードは日本国を挙げてのPKIを使った所有認証事業です。FIDOはグローバル企業が市場の覇権を取るための認証事業です。グローバルを目指す組織は、いかにしてユーザー認証を手中に収めるかに躍起となっています。
情報認証
ユーザー認証が確立してくると、次に来るのが情報の認証だと予想しています。だって、認証したユーザーが”しでかした”らお手上げですから。(^^;USBメモリによる大量の情報漏えい、クラウドサービスで大公開なんて事例は、誰が漏らしたかが明確になるだけで、本質的な解決策はまだなく、あくまでもユーザーのリテラシーに頼る解決策のみが現状です。だからこそのスマートフォンなどの所有認証などを組み合わせる施策が検討されているのです。さらなるユーザーの囲い込みを目指してこれからもますます活性化していく領域なのでしょう。
以上の様に世間はまだまだユーザーの認証に終始している状況です。ユーザー認証が洗練された未来には、そのユーザーが作り出す情報そのものへの認証「情報認証」が求められると思われます。今はAKIが提唱しているに過ぎませんが…近い将来、もしもWeb3.0の時代が本格的になってきたら必ず必要となってくる技術だと確信しています。「分散ネットワークでのアクセス制御が可能」な技術とその有用性は、かなりの価値になるのではないでしょうか。
AKI TLSとSureArchiverの役割分担
AKIではユーザー認証が完了したら、KeyCaseのゼロ知識認証を行い専用鍵を獲得します。獲得した専用鍵はAKI TLSに引き渡され、サーバー（読み手）とユーザー（作り手／持ち手）との情報交換に利用します。KeyCaseのゼロ知識認証はSureArchiverの技術そのものです。AKIの技術が入れ子で採用されているので、どうしてもわかりにくい面がありますが、非常にシンプルで強固なセキュリティとなっています。AKI TLSとSureArchiverの非対称鍵の使い方の違いを、ざっくりと示します。
AKI TLSは専用鍵を継続して使い、SureArchiverでは常に新しい専用鍵で相互押印する、という違いがあります。KeyCaseはこの２つの技術を組み合わせた、作り手／読み手／持ち手モデルの最後のピースなのです。
専用鍵について
KeyCaseに格納されている専用鍵について、もう少しだけ説明を続けます。PKIの秘密鍵との比較を以下に示します。
KeyCaseに格納されているペア鍵は「秘密」を持っていません。ですからKeyCase自体に情報漏えいの概念を持ち組む必要がありません。あくまでもペア鍵の関係性で暗号化と復号の関係性が秘密であり、この関係性を第三者が模倣できない様にSureArchiverによる唯一性を利用した仕組みです。サーバー（読み手）とユーザー（作り手／持ち手）との関係が適切であれば暗号化と複合が成立しなければならない前提となるので、鍵を公開する必要もなくなり与信の担保も不要です。
AKIがRSA暗号にこだわらない理由
本記事に至るまで、説明をわかりやすくするためにRSA暗号をベースとしていました。KeyCaseはサーバー（読み手）とユーザー（作り手／持ち手）との初回接続時に必ずKeyCaseの作成を行います。ですので、お互いのペア鍵を作りあい持ち合う事もできます。将来、より高度な非対称鍵暗号が開発された場合も対応可能です。
KeyCaseとは：ユーザー認証と情報認証とを連携させる仕組み
個人認証と情報認証を連携するアプリケーションがKeyCaseです。グローバル企業の高度なユーザー認証技術とAKIの情報認証を組み合わせた、新しいデジタル所有認証の事例です。AKIのKeyCaseが本格的に活用される未来、パスワードに縛られるず気楽に最新技術を活用できる未来を夢見ています。本当に、本当に、そうあってほしいです。
ロール（役割）の設定と利用サービス
さて、より詳細な説明に入っていきます。プログラム構造の説明に入る前に、利用者組織やユーザーの特性を明確にしておきます。組織やユーザーの役割をちゃんと定義しておかないとなかなか説明が難しいです。詳細な設計書を掲載しても意味がないので、「組織ロール」「ユーザーロール」として役割視点での説明とします。あくまでもPoC的な簡易な組織構成／ユーザー構成ではありますが、必要十分な検証を行う事ができました。
ロールの設定
今回のPoCでは２つの組織ロール、４つのユーザーロールで構成しました。それぞれのロールについて簡単に説明します。
組織ロール
組織ロールはSureArchiverサービスを提供する「SureArchiver運営」と、サービスを利用する「テナント」です。
| 組織ロール | できる事 | 出来ない事 |
|---|---|---|
| SureArchiver運営 | ・SureArchiverサービスの提供 ・テナントのメンテナンス ・利用状況のモニタリング ・AWSシステムメンテナンス | ・全てのサービスリソースの改ざん、干渉 →分散ログによる論理的縛りで担保 |
| テナント | ・SureArchiverサービスのビジネス利用 | ・SureArchiver運営の担当領域全て ・全てのサービスリソースの改ざん、干渉 →分散ログによる論理的縛りで担保 |
ユーザーロール
| ユーザーロール | できる事 | 出来ない事 |
|---|---|---|
| SureArchiver運営者 | ・テナントのメンテナンス（登録、削除） ・初期テナント管理者の登録 | ・SureArchiverサービスの利用 ・テナント側ユーザーの担当領域全て |
| テナント管理者 | ・テナント側ユーザーのメンテナンス ・アーカイブファイルの利用（作成、無効化等） | ・SureArchiver運用者の担当領域全て |
| アーカイブオーナー | ・アーカイブファイルの利用（作成、無効化等） | ・SureArchiver運用者の担当領域全て ・テナント側ユーザーのメンテナンス |
| アーカイブユーザー | ・アーカイブファイルの利用（参照のみ） | ・SureArchiver運用者の担当領域全て ・アーカイブファイルの作成 |
各ロールの関係は以下の通りです。
非常にシンプルに取りまとめました。AKIに固有の条件などは基本的にはありませんから、適応ユースケースに応じて柔軟に変更する事が可能です。
利用サービス
説明にあたり、使用するサービスの事前説明を行います。フロー図を読む際の参考情報です。
| サービス名 | 提供 | 説明 |
|---|---|---|
| Amazon API Gateway | AWS | AKIサービスをRESTful-APIとして公開する為の基盤システムです。 RESTful-APIとする事で柔軟にAKIサービスを活用する事が可能です。 ※本サービスは基盤システムなのでフロー図上は省略します。 |
| AWS Lambda | AWS | AWSが提供するサーバーレスコンピューティングサービスです。 ※本サービスは基盤システムなのでフロー図上は省略します。 |
| Amazon Cognito | AWS | ユーザーの認証、承認、およびユーザー管理機能を提供します。 |
| Amazon DynamoDB | AWS | フルマネージド、サーバーレスのNoSQL データベースです。 ユーザー認証に関わる諸情報のコンテナとして利用します。 |
| Amazon S3 | AWS | データを保存するオブジェクトストレージです。 AKIDサービスで作成された鍵束情報のコンテナとして利用します。 |
| SureArchiver | AKI | 情報認証を行うWebアプリケーションです。 |
| AKI-Archiver | AKI | 暗号オプションも利用できるAKIが提供するデジタル署名モジュールです。 RSA暗号等のロジックも内包しています。 将来の多様な非対称鍵暗号にも対応可能です。 |
| KeyCase | AKI | SureArchiverのアーカイブシステムを拡張し、ユーザー毎の専用鍵を安全に格納し、ユーザー責任で所持管理できるファイルを指します。 Amazon Cognitoと連携しサインインに連携して専用鍵を取り出しAKI TLSによる署名付きE2E通信を実現します。 |
| AKIDサービス | AKI | AKIDを使った鍵束の登録と取り出しのサービスを提供します。 |
| AKI TLS | AKI | ユーザー毎に設定された専用鍵（ペア）を使って署名付きE2E通信を行うモジュールです。 |
| Web Storage | HTML5 | ウェブサーバー側からの制御によりWebブラウザなどのWebクライアントにデータを保存する仕組みです。 アクティベーション時に作成したKeyCaseはこの領域に格納します。 |
ユーザーのスタートアップ（Amazon CognitoとKeyCaseの連携）
SureArchiverのロール情報が定まりました。本章では、ユーザーがどの様に登録され、専用のKeyCaseを所有するまでの具体的な処理フローについて説明します。ユーザーが登録されSureArchiverを利用できるまでには、以下のステップが処理されます。
次章にてステップバイステップで内部フローをさらに踏み込んで説明します。その際にはAmazon Cognitoなど主要なITサービスとの連携もある程度細かく解説しています。各サービスとの連携を細かく解説する事で、さまざまなITサービスへの応用に発展できればと考えます。既存の、そしてこれから発表されるであろう最新の認証システムにも柔軟な設計である事を理解頂く様注力いたしました。
テナントの契約
クラウドでは一般的なテナント型サービスモデルを採用しました。 SureArchiver運営事業者にテナントを開きたい事業者がサービス利用を申し込む形式です。テナント契約時に、代表となる管理者のメールアドレスを申請します。SureArchiver運営事業者が新規登録するのは唯一この時のみです。
新規ユーザーの招聘
管
管理者権限を持つアカウント（SureArchiver運営者、テナント管理者）のみがユーザーの登録が可能です。ユーザー登録が正常に行われると、当該ユーザーへ招待メールが送信され登録が完了します。テナントの利用開始時と利用中ではユーザー登録の経路が異なりますので、フロー図はそれぞれのケースで作図しました。ユーザーが所属する組織が違うだけで、基本的なフローはほとんど変化はありません。招待メールで以下の情報が伝えられます。
- アクセスURL
- ユーザー名
- 仮パスワード
テナント管理者の登録と招聘
テナント利用開始時はSureArchiver運営者が、対応するテナントの管理者を登録する必要があります。SureArchiver管理者が契約締結のタイミングで一度だけ実行されます。
各サービスコンポーネントとのやり取りを時系列でフロー図を示します。必ずしもテナントのセキュリティ境界の中に存在する必要はありませんが、下図においては最初の専任者としてテナントの境界内に居るイメージで取りまとめています。
テナント申請時に指定した方宛に招聘メールが届き、初回アクセスを待っている状態に遷移します。
テナント管理者／アーカイブオーナー／アーカイブユーザーの登録と招聘
テナントとして通常利用している状態でのユーザー登録は以下の通りです。アーカイブオーナー、アーカイブユーザー、そしてテナント管理者を追加する事ができます。
最初のテナント管理者以外はテナント管理者が自らの責任で登録が行われます。SureArchiver管理者は、テナント内で登録されたユーザーがどのセキュリティ境界に所属しているかには関与しません。
登録したユーザーに招待メールが届き、初回アクセスを待っている状態に遷移します。
ユーザーロールによる待ち状態の違いはありません。
SureArchiverへサインイン
招待メールを開いて記載されているURLを開くとSureArchiverウェブアプリケーションがスタートします。招待メールに記載されたユーザー名と仮パスワードを入力してサインインします。
アクティベーション・KeyCaseの作成
最初のアクセスであればAKIDが未登録状態なのでアクチベーションが自動実行されます。「KeyCaseの生成はこのステップでしか行われません」。
上図をステップバイステップに近い形で表現してみたのが次のフロー図です。エラー処理や仮パスワードの変更などKeyCaseの生成にあまり影響のない処理は割愛しています。Amazon CognitoとAKIとの連携のイメージを読み取っていただければと思います。
もしもKeyCaseを紛失してしまったらユーザー登録から再実行しかありません。ユーザーの責任で保存管理してもらう前提でユースケースとしてデザインしています。そのため、最後のステップでユーザーに外部媒体へ保存する様促すガイダンスを表示します。保存自体は任意にいつでも実行する事ができます。また、普通の秘匿性のないメディアに保存しても問題はありません。
メールの有効性検証
次回以降のユーザーの真正性評価については、シンプルにユーザー登録時のメールを使って行います。より高度なユーザー認証を採用する事も可能です。
SureArchiverの利用
AKIDが登録され、メールの真正性検証も完了してしまえばこっちのものです。ユーザーごとに専用鍵がKeyCaseから取り出せるのでユーザーとサービスとでE2E通信が可能です。AKI TLSを使った安全な情報交換が実現します。
上図をステップバイステップに近い形で表現してみたのが次のフロー図です。エラー処理など説明の簡素化のために影響がない処理は割愛しています。Amazon CognitoとAKIとの連携のイメージを読み取っていただければと思います。
いささか細かな説明となりましたが、以上を以てSureArchiverウェブアプリケーションを実現しました。
既存のIT認証と連携しつつ、新しい技術である「情報認証」の評価実験が出来ます。
アーキテクチャレイヤ
Keycaseのアーキテクチャレイヤは以下となります。
クライアントとサーバーの構成概要は以下のとおりです。
SureArchiverの各種ロールを整備し、ユーザーごとに専用鍵を配布する仕組みを組み込む事で、ウェブアプリケーションとして完成しました。机上の倫論ではなく、実際に稼働する事を証明できました。
実際に使ってみると、ありそうでありえない、独特のアーカイブファイルシステムって感じです。
配布済みのアーカイブファイルを遠隔で無効にできる機能は想像以上に便利かもしれません。😄
将来構想
当記事の実装ではAmazon Cognitoを使った「パスワードによる知識認証」でユーザー認証を得て、以降をパスワード レスな情報認証としました。当ブログのテーマ「パスワードなんて大嫌い！」に関しても「達成していない！」とお叱りの声も聞こえてきそうです。
先にも説明した通り人の認証は、GAFAが推し進めるスマホ認証やマイナンバーカードによる所有物認証などとのマッシュアップを想定していますので自ずと実現できるものと確信しています。ともかく、世はユーザー認証に関して躍起になって技術革新を進めていますので、成果の共有を期待して待っています。
Auth0（高度なユーザー認証システム）との連携
今回のユーザー認証はAmazon Cognitoを使って検証しましたが、実運用で利用するには標準機能だけでは十分とは言えないと感じました。よりリッチなユーザーの招待機構が必要だと思いましたし、管理コンソールも必要です。さらにはユーザー認証技術の進歩にも対応しないとせっかくの情報認証も絵に描いた餅になってしまうと確信しました。
幸い、Auth0のセールス担当様とお打ち合わせの機会がありました。世の中は「ユーザー認証」に注力している真っ最中であり、これから先、さまざまな仕組みが今後も発表されてくるのは確実ですし、Auth０をユーザー認証のレイアに据える事は非常に賢明な施策です。
上図の通りAmazon CognitoをAuth０に置き換える事で、将来の技術的陳腐化を抑止する事ができそうです。
今後の活動で、ぜひとも導入検証し知見としたいです。😄
GAFAによるエンドユーザーE2Eの本格化
最
最新のAppleでは、ついにE2Eが実現されつつある様です。その場合、KeyCaseの所有鍵が単純に置き換えてればいいかと考えています。
AKIが実現したいのは個人の認証ではなく情報の認証なのですから。今、実現されつつあるE2Eはあくまでも自身のデータの保護であって、情報の認証には至っていません。ユーザーの認証が整いつつある今だからこそ、情報認証の必要性がこれからの話題になってくると思われます。それこそAuth0との連携でクリアされると考えています。
まとめ
SureArchiverとして必要な機能は全て実装する事ができました。しかしながら、今回のPoCではログ分散の実装は至りませんでした。もちろん、サーバーサイドには分散直前ですが、改ざんを防止する新しいログシステム自体は開発済みです。ですから、作り手鍵の廃棄などに不正があったとしても、改ざん履歴などは十分に検査が可能です。
今回のPoCでは証拠情報の分散の実装は見送っています。時間と開発費は新たなイノベーションの創出には最大の課題である事を再認識した次第です。是非とも本格的な実装の際には、分散ログの完成を目指したいです。
AKIの技術解説、最後の記事は「分散ログ」についてです。
コメント