AKI Archiverユーティリティを使って、簡単にAKIDサービスが利用できる環境が整いました。次に整備するのは、クライアントとサーバーとの熱いホットラインです。本書では、AKIを使って、従来のインターネット通信にさらなる安全で確実なセキュアネットワークを構築します。もちろん、人に優しいセキュリティが前提です。秘密を持たず持たせないアーキテクチャデザインを引き続き検討します。
はじめに
AKI TLSはクライアントごとに専用のAKIDと作り手鍵（秘密鍵に相当）を用意し、サーバーとE2E（End2End）で情報交換が行える様にするユーティリティです。本書ではAKIDサービスに関わる作り手鍵/読み手鍵の生成や配置は既に完了している時点からの説明とします。今後、記事が書く進む中で関係性の説明や初回アクティベーションの考え方に言及してまいります。以降の説明では、以下の鍵ペアの関係性が完了している（アクティベーション完了状態）を前提に説明を進めます。ご承知おきください。作り手/読み手モデルの鍵ペア概要は以下の通りです。
RSA暗号技術であれば、クライアント（作り手）用の鍵とサーバー（読み手）の鍵を同じ鍵で対応する事ができます。この特性を利用する事で以下の図の様に整理できます。
AKIでは説明を簡単にするためにRSA暗号を前提とした説明を多く採用していますのでご留意ください。非対称鍵暗号の視点ではリクエストとレスポンスそれぞれに専用の鍵ペアを当てることも可能ですし、セキュリティ上も向上する事は明らかです。AKIは問題なく採用できる仕組みを設計に組み込んでいますのでご安心ください。あくまでも説明を簡単にする目的でRSA暗号を利用しています。
セキュアな通信
クライアントとサーバーとはさまざまな方法で情報交換を行います。インターネットという誰もが接続できる空間では、この情報は容易に盗み見る事が可能だと考えるべきで、この状況を「ゼロトラストな状態」と最近は呼ばれています。セキュア通信とは、情報を暗号化してから通信することでゼロトラストに対応する事を意味しています。
SSL/TLSとは
インターネットにおいて標準と言えるセキュア通信技術です。ほぼ全てのサーバーはSSL/TLSで接続されることが当たり前となっています。
SSL/TLS接続後は、サーバーの情報に従いパスワードなどクライアントの知識認証でシステムへの接続が完了します。あくまでもセキュアな通信を提供するだけの仕組みです。通信自体はクライアントが降り出した共通鍵なので、通信自体そのものにはフォレンジック特性はありません。AKIとの違いを理解いただく上で重要な要点です。
AKI TLS
まず最初に、AKI TLSはOSI(開放型ネットワーク間相互接続規格)の「トランスポートレイアへの実装ではない」事をご理解ください。「これはSSL/TLSの置き換え？」などの誤解を避けたくコメントした次第です。(^^;
SSL/TLSとのマッシュアップ
現在、ウェブの世界ではSSL/TLSは当たり前です。ですから、AKI TLSはSSL/TLSを前提にアプリケーションレイア（OSI-7）へ実装しました。SSL/TLSが提供するセキュア通信の上で、AKI TLSの初回アクティベート（鍵ペア交換）を行う事で鍵ペア漏えいの不安をなくせます。そして、このアプローチは既存のITシステムへの組み込みが問題なく行える事を説明することにもつながります。例えば今回の実証実験ではAWS上でAKI TLSが問題なく機能する事を検証できました。検証したAWSサービスを以下に列挙します。
- AWS Lambdaの上にサーバーシステムを構築
- Amazon Cognitoで人の認証
- AKI ArchiverユーティリティをGo言語で実装
- React.jsを使用してWebアプリケーション（SureArchiver）を構築
- SureArchiverを使ってKeyCaseサービスを用意し、鍵ペアのアクティベーションを提供
非常にオーソドックスなウェブシステムとして開発しました。この成果はAKI TLSが、既存の多様なITシステムに容易に導入できる証と捉えています。
ペイロードの署名
AKI TLSの具体的なフローは非常に単純です。
- クライアント→サーバー（リクエスト）
- AKI Archiverを使用してリクエストのペイロードにAKI署名＋暗号を施します
- 作成したAKI署名を相対するサーバー（読み手）へ送ります
- サーバー（読み手）は認証し、ペイロードを取り出します
- サーバー→クライアント（レスポンス）
- AKI Archiverを使用してレスポンスのペイロードにAKI署名＋暗号を施します
- 得られたAKI署名を相対するクライアント（読み手）へ送ります
- クライアント（読み手）は認証し、ペイロードを取り出します
非常にシンプルにE2E通信が成立しています。AKIはクライアントとサーバーとの間に、デジタルな専用回線「ホットライン」が容易に提供する事ができます。そして、ホットラインで取り交わされるメッセージ全てがデジタルな証拠能力を持つ事に着目してください。これは、NISTにて推奨される「CDM（Continuous Diagnostics and Mitigation：継続的診断および対策）」を実現する手段にもなりえそうです。
以上がAKI TLSが提供するデジタルホットラインの概要です。
AKI TLSのアーキテクチャレイヤ
AKI TLSのアーキテクチャレイヤは以下の通りです。
システムへの組み入れ
作り手/読み手モデルへAKI TLSを組み込んでみます。ここでは、AKIDサービスに合わせ、RSA暗号を採用した場合の図式とします。
以上、AKI TLSでクライアントとサーバーがホットラインで繋がりました！
通信ログのイノベーション
サーバーはクライアントを個別に認識しつつ、すべての通信を常に検証しながら行う事が可能です。通信ログをストレージに保存すれば、そのまま証拠能力を持ったログ記録が行えます。この様な特性は今までのITシステムでは実現する事は不可能でした。今までは、証拠たる記録とするために、多くのコストを費やしてログのクレンジングが必要でしたが、AKI TLSはそのままでも高い証拠能力を提供します。本特性の詳細は「分散ログ」で詳しく開設する予定です。
まとめ
本記事にて既存のSSLとAKI TLSとの関係性を確認できれば幸いです。AKIはさまざまな界面で鍵ペアを使用するので、人類にとっては直感的に理解しずらいです。😅 本当、説明するのがとても大変なんです。だからこそ世の中PKI一択だっのかなぁとさえ思う事が多々ありました…少し脱線しました、すみません。AKIは、鍵ペアの論理的絶対の関係性で構築されているからこそセロトラストに耐えられるホットラインを実現できます。
次の記事ではいよいよ新しい概念「情報認証」と「持ち手」が登場します。今までは従来のITシステムのセキュア通信の延長線上にある考えでした。セキュア通信の中でしか確保できなかったAKI Archiverを、通信以外のメディアに永続的に残す仕組みを検討し情報認証という概念が生まれました。そして情報認証の概念から、ゼロトラストを意識しなくとも安全に情報を所有する事ができる持ち手という存在、さらには情報認証と持ち手が自由に情報を管理する仕組み「SureArchiver」へとつながります。
コメント