はじめに
AKI（Asymmetric key Infrastructure / 非対称鍵暗号基盤）はPKI（Public Key Infrastructure / 非対称鍵暗号基盤）の親戚です。ですからAKIで実現できる事はPKIでもほぼ実現できます。PKIは非対称鍵暗号を効率よく使うことができる優れたシステムですが、鍵を公開するが故に適用しにくいユースケースも散見します。例えば大量に秘密鍵と適切な与信が付いた公開鍵証明書を配る場合に掛かるコストが課題です。AKIは、このようなPKIを利用したいけどコストや運用面で断念していたユースケースをカバーするために設計しました。
2022年7月には「SureArchiver」という具体的なPoC（Proof of Concept：実証実験）にて確証を得る事ができました。もちろん、既存のITシステムやPKIとも共存できる様設計しましたので、さまざまな展開が可能となっています。既存システムのさらなる成熟にお役立ちできればと考えています。SureArchiverは、実際に動作確認していただくことも可能です。ご興味がございましたらご連絡ください。
本書はPKIを比較事例に取って、AKIの特徴をご紹介します。PKIの技術的概要は「PKIの特徴・暗号技術の概要をまとめました」に取りまとめています。
暗号のカテゴリーと種類
AKIはPKIと同じ暗号技術で構成されています。採用する暗号技術も全く同じです。
共通鍵暗号方式
PKIではSSL/TLSのハイブリッド暗号での利用が中心でした。AKIは認証や守秘性そして唯一性などの情報セキュリティ実現するために、積極的に共通鍵暗号を活用しています。
非対称鍵暗号
PKIにおける秘密鍵は「公開鍵」を「生成」する役割を担いますが、採用する暗号技術によって仕様が変化します。例えばRSA暗号であれば鍵ペアの生成時に「秘密鍵」に「公開鍵」を格納（暗号化は任意）し、取り出す行為を「生成」と定義しています。暗号技術によっては秘密鍵から文字どおり公開鍵を生成できる技術もあるでしょう。AKIはこの鍵ペアの役割分担を排除する事で、鍵の管理責任を最小にします。秘密鍵という重要な役割がなければ、さらには所有しなくても済むのであれば、所有者が担うリスクは最小となるとした考えです。AKIでは鍵ペアの関係性を「AKID（AKi-Index）」で表します。AKIDは「生成時のみに確定される」「対応する鍵とは非可逆」な特性を持っており、この特性を「証明書相当の与信」としています。
- システムエンジニア時代を振り返ると、こういった鍵の運用設計は部下の仕事なので、いつも心配の種だったことを思い出します…💦
暗号の使い方
AKIでの暗号の使い方を以下に取りまとめます。主にPKIから拡張した事項を中心に補足します。
認証（Authentication）
特定のデータの出自を論理的に証明する点ではPKIと全く同じです。AKIでは守秘性や改ざん証明をシステムに取り込むために「AKI署名フォーマット」を考案しました。AKI署名フォーマットはより署名の活用範囲を広る事ができます。
AKI署名フォーマットは以下の２つの種類があります。
- AKI署名
- 対象データの署名情報
- 署名対象データ
- AKI署名＋暗号オプション
- 対象データの署名情報＋非対称鍵暗号化した共通鍵
- 共通鍵で暗号化した署名対象データ
- フォーマットの詳細は後ほど説明します
- AKI署名＋暗号オプションは事項「守秘性」にて補足します。
守秘性（Confidentiality）
AKI署名＋暗号オプション付きを選択する事で、データの守秘性と認証の双方をカバーします。また、共通鍵自体が署名内に「ゼロ知識証明」状態で格納されているので「認証にて自動複合」する事ができます。
完全性（Integrity）
AKI署名は署名情報やゼロ知識暗号化をデータに施す事で、高い完全性を付与する事ができます。
否認防止（Non-Repudiation）
データ毎のやり取り自体に認証が組み込まれているのでトランザクション自体に高い証拠能力を付与します。
唯一性
AKIでは新たに「唯一性」を追加します。改ざん性の拡張概念であり、改ざん検知を行うだけでなくその情報が唯一の存在である事を確認できる特性です。唯一性が付与されたデータの複製や移動などは自由に行えます。どれだけ複製しようが情報的に唯一である事を確認できます。AKIではデータに署名を施す事を「情報認証」と呼称します。
AKIについて
AKIについての要件を取りまとめます。
提供する機能
AKIが提供する機能を表にまとめました。
| 提供機能 | 説明 |
|---|---|
| 暗号化（Encryption） | データを暗号化して、第三者の盗聴を防ぐ。 |
| デジタル署名（Digital Signature） | データに対して、情報作成者の署名を施します。署名を検証する事で、データ作成者の確証を得る事ができます。情報認証を検証する場合は、唯一性の確証を得る事ができます。 |
構成要素
AKIでは公開鍵方式ではないので第三者の保証を必要としません。ネットワーク通信モデルではクライアントとサーバーがそれぞれの方向性で「作り手」「持ち手」となってE2E通信をAKI署名フォーマットを使って通信します。データをAKI署名フォーマットで作成し、持ち手が情報認証として所有します。
| 要素 | 説明 |
|---|---|
| 認証局 | ありません |
| 登録局 | ありません |
| リポジトリ | ありません |
| アーカイブ | ありません |
| 作り手（Creator） | 情報認証（AKI署名を含む）を作成する人の総称です。読み手とは専用鍵を使って認証しあい、AKI TLSを使ってE2E通信します。 作り手は情報認証を作る事が出来ます。 作り手は相互押印を行う事で、「情報認証の永続化」を行う事も出来ます。 情報認証のアクセスコントロールが出来ます。 |
| 読み手（Reader） | 情報認証を検証する人の総称です。作り手に相対する存在です。 作り手とは専用鍵を使って認証しあい、AKI署名を使ってE2E通信します。 読み手は情報認証の検証依頼を受ける事が出来ます。 作り手の指示に従い、情報認証へのアクセスコントロールを行います。 |
| 持ち手（Owner） | 永続化した情報認証を所有する人の総称です。 読み手とは専用鍵を使って認証しあい、AKI署名を使ってE2E通信します。 読み手を介して情報認証のアクセス権を取得し読みます。 |
| AKIDサービス | AKIDサービスは鍵ペアの片割れを預かりAKIDを発行します。 複数の鍵を同時に預かる事で情報認証に必要な「相互押印」を実現します。 |
| KeyCaseサービス | 読み手が提供する認証サービス様の専用鍵を発行するサービスです。 発行されたKeyCaseはAKI電子署名フォーマット＋暗号オプションでゼロ知識暗号化されているので、読み手/持ち手として人的認証が完了しない限り使う事ができません。 |
鍵ペアについて
前項にても説明しましたが、AKIで生成した鍵ペアに役割分担は設定しません。読み手から振り出すAKIDだけが鍵ペアの関係性を保証する情報になり、これをPKIの公開鍵証明書の代わりとして使います。鍵自体の役割分担がなくなるので公開鍵証明に必要な与信情報が不要となり、鍵の運用コストを最小にします。
図 2 PKIでの鍵の関係を俯瞰
サーバーが証明書の所有者となり、クライアントが証明書の利用者です。そして、認証局がサーバー証明書に与信を与えています。認証局の与信で、クライアントは安心して証明書を利用する事が出来ます。
図 3 AKIでの鍵の関係を俯瞰
サーバーとクライアント双方で鍵ペアを持ち合います。鍵ペアはAKIDで関係つけられています。サーバーへのリクエストでは作り手がクライアント、読み手がサーバーです。レスポンスはサーバーが作り手、クライアントが読み手の関係へと変化します。複数の鍵ペアを一つのAKIDでまとめる事が出来ます。
図 3-1 AKIでの鍵の関係を俯瞰（RSA暗号方式の場合）
RSA暗号は暗号と復号の双方向性が成り立つ方式なので、一つの鍵ペアで作り手/読み手モデルを成立する事が出来ます。
AKI署名のフォーマット
PKIでの署名は非常にシンプルで、署名したいデータのハッシュ値を秘密鍵を使って署名（暗号化）したものです。AKIは専用の署名フォーマットを規定し、この一連の処理をライブラリとして提供します。ライブラリとする事で容易に暗号が使える様になりますし、ゼロ知識証明にも貢献します。
AKI署名
情報の認証と完全性を提供します。APIにて署名作成サービスを提供するので、容易に署名を利用する事ができます。
AKI署名＋暗号オプション
情報の認証と完全性を提供し、さらに守秘性を提供ます。情報の暗号/複合には高速な共有鍵暗号を利用し、大容量の情報も暗号化して署名する事ができます。APIにて署名作成サービスを提供するので、容易に暗号化付き署名を利用する事ができます。
データのAKI署名を作成する
情報をAPIに渡す事で簡単に署名が得られます。
暗号化して渡す場合お、ローカルで暗号化するので情報漏えいのリスクを低く抑える事ができます。
鍵ペアの交換がほぼ存在しないので、鍵の漏えいリスクも最小です。
ネットワークへ送出される時点では基本的に暗号化されているので盗聴リスクも最小です。
AKI署名を検証する
持ち合わせが前提の鍵で認証するので、成否判定がロジカルに行えます。
署名作成者が認証の拒否を設定すれば、以降の署名検証を全て拒否する事ができます。
共通鍵は認証完了時点で入手できるのでゼロ知識認証にて情報の復号処理が行えます。
AKI TLSについて
SSLはOSI(開放型ネットワーク間相互接続規格)のセッション層に組み込まれますので、その上位層は容易に利用する事ができます。AKIはアプリケーション層に構築していますのでSSL/TLSとも問題なく共存できます。
SureArchiverのPoC（Proof of Concept：実証実験）では、AWS Lambdaの上でAKIのE2E暗号通信を実装いたしました。今やHTTPSは常識なので、PoCにおいても既存APIサービスに上に実装できる事を確認しました。
うまくSSL/TLSと連携できる事を確認する事で、今後の既存システムに鍵ペアの生成や交換、そしてクライアントへの保存方法等の実現検証を行う事ができました。
- AKI Whitepaperでは「AKI署名１」及び「AKI署名２」を「保証書１」「保証書２」と記述しています。これはAKI署名を押印操作に見立てた説明となっているからです。本書はPKIと比較の意味合いもある為保証書をAKI署名という表現で統一しています。
- AKIの用語としては AKI White paperが真となります、ご承知おきください。
AKIのアーキテクチャレイヤ
AKIがどの様な機能を提供できるのか、既存のPKIを比較対象に説明してまいりました。
PKIとは異なる機能を提供するためアーキテクチャ構造はPKIとは異なります。
続く記事では、AKIのアーキテクチャについて掘り下げていきます。
読み進んでいただく上でのインデクスとして、現時点でのAKIアーキテクチャレイアを以下に示します。
まとめ
PKIとは違う視点で非対称鍵暗号の新しい使い方が提案できれば幸いです。
アーキテクチャレイアの基礎を担う「AKIDサービス」についての資料を用意しました。
ぜひご一読ください！！
AKIのコンセプトをホワイトペーパとして取りまとめています。
また、AKIのPoCアプリケーションをベースに具体的な活用ユースケースの記事も用意いたしました。
こちらも読んでいただければ幸いです。
セキュリティインシデントのニュースを読んで…
セキュリティ事故や事件から、AKIがどの様な抑止力になるか、私の私見ですがコメントしておきます。
秘密鍵の流出
こういった漏えい事故は数えきれないほど起きています。
当事者になっちゃったら、もう、それこそ、生きた心地がしません。本当にゾッとします。
基本的には、漏えいした人や組織が責任を取る事になるのですが、結構かわいそうだと思っています。
人はミスをしてしまうものですし、ミスをリカバリーできる考え方こそが必須ですよね。
私も現役の頃は、事件事故の度にどんどん厳しくなっていくのが残念でたまりませんでした。ルールが追加される度に、それこそなんのためのデジタルなのか？と疑問でした。
結局、インシデント発生時に組織としての言い訳を用意している風にしか感じられず、だからこそ、組織ぐるみの不祥事が起こる度に、現場の不利益だけが積み上がっていくありさまに憤慨もしていました。
記事では「最善の対処法としてAPK署名スキームv3のAPKキーローテーションを採用する」となっています。
即効的な対策は行えず、継続的な活動で収束させていく手段しかない事を明示しています。
秘密の漏洩は検出できない
単に課題は「秘密」の漏えいは事後でしか判別できない事こそが問題である事は明白です。
しかも、その明白な状況にも関わらず、実は決定的な解決策が存在していません。
AKIではどの様に対処するのか
AKIはデジタル署名の考え方を「書き手/読み手/持ち手モデル」という新しいアプリケーションモデルでステップアップを狙います。
この新しいモデルでは、基本的に「情報に唯一性」を与える事が可能です。情報に唯一性を与える事「データを常に検証」する前提を置く事が出来、配布した情報の永続的な制御が可能です。例えば、アプリ個別に専用の刷り切りのデジタル署名を施したり、回数制限や個別認証などを安価に実現できます。
現在、AKIで実現の可能性が見えてきたユースケース活用例についても随時記事を掲載していく予定です。
引き続き、当ブログに注目いただければ幸いです。😄
コメント