8.4 認証プロトコル
ここまで本章ではメッセージの暗号化と認証子の作成、そして暗号で必要な鍵の事前配布を説明した。後は全てのメッセージに認証子を付け、機密性が必要な場合はメッセージの暗号化を行えばセキュアなプロトコルが手に入ると思うかもしれない。
しかし、それで問題が解決するほどプロトコルのセキュア化の問題は単純ではない。主な理由が二つある: まず、攻撃者が以前に送られたメッセージのコピーを送信する再送攻撃 (replay attack) という問題がある。例えばウェブサイトに何かを注文するメッセージが再送されると、ウェブサイトは同じ商品が二つ注文されたと受け取るかもしれない。攻撃者はオリジナルの送信者が作成したメッセージをそのまま再送するので、再送されるメッセージはオリジナルの送信者が送信したメッセージではないにもかかわらず正当な認証子を持つ。明らかに、セキュアなプロトコルにはメッセージの独自性 (originality)を保証する手段が必要になる。
再送攻撃に似た妨害再送攻撃 (suppress-replay attack)と呼ばれる攻撃も存在する。この攻撃では、攻撃者がメッセージの送信を通常より遅れさせる (例えばメッセージを横取りして後から再送する) ことで、適切でないときにメッセージを到着させる。例えば攻撃者は商品の注文を都合の悪い時間まで遅らせるかもしれない。この攻撃で攻撃者が送信するメッセージは字面だけを見ればオリジナルと同じではあるもの、時間的にはオリジナルと異なっている。ここから分かるように、セキュアなプロトコルは適時性 (timeliness) を保証しなければならない。独自性と適時性は完全性 (integrity) に含まれると考えることもできるだろう。この二つの要素を保証するには、メッセージのやり取りが絡む非自明なプロトコルが必要になる。
これまでの議論で考えていない二つ目の問題はセッション鍵の生成方法である。セッション鍵 (session key) とは一つのセッションだけで使うためにその場で生成される秘密鍵暗号の鍵を言うのだった。この処理にも非自明なプロトコルが必要になる。
この二つの問題には認証という要素が共通している。メッセージがオリジナルと異なっていたり適切な時間に届かなかったりしたら、そのメッセージは本物ではなく、メッセージが主張する送り主から送信されたものではないと実用的観点から言ってみなさなければならない。そして明らかに、新しいセッション鍵を誰かと共有するときは、正しい人物と共有していることの保証が必要になる。通常、認証プロトコルは認証と同時にセッション鍵を生成する。そのためプロトコルが終了した時点でアリスとボブは互いに相手を認証し、新しいセッション鍵を利用する準備が整う。セッション鍵を使わないと通信のたびに認証が必要となるのに対して、認証と同時にセッション鍵を生成すれば以降のメッセージの効率的な認証が可能になる。一般にセッション鍵生成プロトコルは認証を行う (ただし注目すべき例外として Diffie-Hellman 鍵交換がある)。そのため、認証プロトコルとセッション鍵生成プロトコルはほぼ同義の言葉として使われる。
認証プロトコルで独自性と適時性を保証するのに使われる中心的なテクニックがいくつかある。特定のプロトコルを見ていく前に、そういったテクニックをまず見ていく。
8.4.1 独自性と適時性を保証するテクニック
本節の最初で説明したように、認証子を使うだけでは独自性を持たないメッセージや適時性を持たないメッセージを検出できない。 一つのアプローチとして、タイムスタンプをメッセージに含めるアプローチが考えられる。当然タイムスタンプ自身が改竄されてはいけないので、認証子はタイムスタンプもカバーしなければならない。タイムスタンプの主な欠点として、離れた場所にあるクロックの同期が必要となることがある。クロックの同期処理自体が複雑なのに加えて、同期処理はセキュリティ脅威から守られた状態で行わなければならない。さらに、離れた場所にあるクロックの同期は完全に正確には行えない点も問題になる ── ある程度の誤差は避けられない。このためタイムスタンプが提供する時刻の完全性は同期の正確さに依存し、完璧にはならない。
もう一つのアプローチとして、ノンス (nonce, 一回だけ使われる乱数) をメッセージに含めるアプローチがある。受信側はノンスが以前に使われたかどうかを確認することで再送攻撃を検出できる。しかし、このアプローチでは大量に生成されるノンスを全て記録しなければならない点が問題になる。一つの解決策として、タイムスタンプとノンスを組み合わせ、ノンスが一定の期間でだけ一意であることを要求する方法がある。こうするとノンスの一意性の保証が現実的に実現可能になり、そのときクロックの同期に正確さはそれほど必要にならない。
タイムスタンプとノンスの欠点を克服する方法としてチャレンジ-レスポンス認証 (challenge-response authentication) がある。チャレンジ-レスポンス認証はタイムスタンプとノンスの片方もしくは両方と同時に利用できる。例えばチャレンジ-レスポンス認証でタイムスタンプを使うとき、アリスはボブにタイムスタンプを送信し、レスポンスメッセージでタイムスタンプを暗号化 (秘密鍵を共有している場合) もしくはデジタル署名 (ボブが公開鍵を持っている場合, 図 202) することをボブに要求する。暗号化されたタイムスタンプは適時性を証明する追加の認証子として機能する。ボブが送り返すタイムスタンプはアリスのクロックで生成されたものなので、適時性は簡単に確認できる: クロックの同期は必要ない。チャレンジ-レスポンス認証でノンスを使うとき、アリスは返信を待っているノンスを記録するだけで済む: それ以外のノンスが付いたレスポンスメッセージは偽物だと確定する。
チャレンジ-レスポンス認証が優れているのは適時性の検証と認証が同時に行える点であり、これは他の方法だと非常に複雑になる可能性がある。結局、新しく生成されたタイムスタンプあるいはノンスを暗号化するための鍵を知っているのはボブ (秘密鍵暗号を使う場合は加えてアリス) しかいない。タイムスタンプとノンスは後述される認証プロトコルの多くで用いられる。
8.4.2 公開鍵認証プロトコル
これからの議論では、アリスとボブの公開鍵が PKI などの手段で事前配布されているものとする。これは「アリスが最初のメッセージに自身の公開鍵証明書を添付し、それを受け取ったボブが証明書の正しさを検証する」といった運用が可能なことを意味する。
図 203 に示す一つ目のプロトコルでは、アリスとボブの間で同期されたクロックが利用される。最初アリスは自身のアイデンティティとタイムスタンプからなるメッセージにデジタル署名を付けて平文でボブに送信する。ボブはデジタル署名でメッセージを認証し、タイムスタンプでメッセージが生成されて間もないことを確認する。そしてボブは自身が生成したタイムスタンプと自身のアイデンティティ、そしてアリスの公開鍵で暗号化した (機密性を保証した) 新しいセッション鍵からなるメッセージにデジタル署名を付けてアリスに送信する。この返答を受け取ったアリスは認証とタイムスタンプの確認を通して新しいセッション鍵を信頼できるかどうかを判断できる。クロック同期の不正確さに対処するために、タイムスタンプに加えてノンスを使うこともできる。
図 204 に示す二つ目のプロトコルは一つ目のプロトコルと似ているものの、クロック同期に依存しない。このプロトコルでも、最初アリスは自身のアイデンティティとタイムスタンプからなるメッセージにデジタル署名を付けて平文でボブに送信する。このプロトコルではクロックを同期しないので、このメッセージの適時性をボブは検証できない。そこでボブはアリスから受け取ったタイムスタンプ、自身が生成したタイムスタンプ、そして自身のアイデンティティからなるメッセージにデジタル署名を付けてアリスに送信する。アリスはボブからの返答に含まれる自身が生成したタイムスタンプを確認することで適時性を確認できる。その後アリスはボブの公開鍵で暗号化した新しいセッション鍵とボブから受け取ったタイムスタンプからなるメッセージにデジタル署名を付けてボブに送信する。このメッセージを受け取ったボブは自身が生成したタイムスタンプを使って適時性を検証することで新しいセッション鍵が信頼できるかどうかを判断できる。このプロトコルでタイムスタンプは簡単にできるノンスとして使われているだけであり、実際ノンスを使っても構わない。
8.4.3 秘密鍵認証プロトコル
通信を行う主体の全ての組に対して秘密鍵を事前配布する運用は非常に小規模なシステムでのみ実用的となる。ここではより大規模なシステムを想定し、各主体はKDC (Key Distribution Center, 鍵配布センター) と共有するマスター鍵 (master key) だけを持つとする。このとき、秘密鍵ベースの認証プロトコルにはアリス、ボブ、KDC という三つの主体が関係する。認証プロトコルが完了すると、アリスとボブは KDC を経由しない直接の通信で利用するためのセッション鍵を手にする。
Needham-Schroeder 認証プロトコル (Needham-Schroeder authentication protocol) を図 205 に示す。この図から分かるように、KDC はアリスから送られる最初のメッセージを認証せず、ボブとは一切メッセージをやり取りしない。その代わり、KDC はアリスが認証プロトコルの残りを自力で行うために必要な情報を含めたメッセージをアリスにしか読めない形で返答する。KDC がアリスに返答するメッセージはアリスとボブの秘密鍵に関する知識を使って作成される。
最初の二つのメッセージで使われるノンスは KDC からの返答の適時性をアリスが検証するために存在する。二つ目と三つ目のメッセージには新しいセッション鍵とアリスのアイデンティティ、そしてこれら二つの情報をボブのマスター鍵で暗号化したものが含まれる。ボブのマスター鍵で暗号化された部分は秘密鍵暗号を使った公開鍵証明書のようなものと言える: この部分はアリスとボブが利用するセッション鍵を記した文書に KDC による署名が付いたものとみなせる。最後の二つのメッセージで用いられるノンスはボブが三通目のメッセージの適時性を検証するために存在する。なお、Needham-Schroeder 認証プロトコルは再送攻撃に対する脆弱性を持つことが知られている。次に説明する Kerberos は再送攻撃への耐性を持つ。
Kerberos 認証
Kerberos はクライアント/サーバー環境に特化した認証システムであり、Needham-Schroeder 認証プロトコルをベースとしている。元々は MIT で開発され、その後 IETF での標準化された。現在ではオープンソースソフトウェアと商用ソフトウェアの両方が存在する。ここでは Kerberos が持つ興味深いイノベーションをいくつか紹介する。
通常 Kerberos のクライアントは人間のユーザーであり、ユーザーはパスワードを使って自身を認証する。アリスのマスター鍵 (KDC と共有される鍵) はアリスのパスワードから導出される ── パスワードが分かれば鍵も計算できる関係にある。Kerberos はクライアントのマシンには誰でも物理的にアクセスできると仮定する。これは、アリスのパスワードとマスター鍵の露出をネットワーク上だけではなくアリスがログインする任意のマシンで最小限にする必要があることを意味する。Needham-Schroeder 認証では、アリスが自身のパスワードを使うのは KDC からの返答を復号するときだけである。そのため Kerberos のクライアント側ソフトウェアは KDC の返答が到着するのを待つ段階になったらアリスに対してパスワードの入力を要求するプロンプトを表示し、返答が到着するとすぐにマスター鍵を計算して復号を行い、次の瞬間にはパスワードとマスター鍵に関する情報を全て消去することで情報の露出を最小化する。ユーザーが Kerberos の存在に気付くのはパスワードを要求されたときにだけである点にも注目してほしい。
Needham-Schroeder 認証において、KDC がアリスに送信する返答には二つの役割がある: まず、この返答はアリスだけが復号できるので、アリスは自身のアイデンティティを証明する手段を手にする。次に、ボブのマスター鍵で暗号化されたセッション鍵とアリスのアイデンティティはボブに提示すべき「チケット」 (秘密鍵を使った「証明書」) となる。Kerberos では、この二つの役割が ── 事実上 KDC が ── 二つに分割される (図 206)。KDC の一つ目の役割は AS (authentication server, 認証サーバー) が担う。AS は信頼されたサーバーであり、アリスに自身のアイデンティティを証明する手段を提供する。AS からの返事を使ってアリスが自身のアイデンティティを証明する相手となるのが KDC の二つ目の役割を担う TGS (ticket granting server, チケット発行サーバー) である。TGS も信頼されたサーバーであり、ボブに提示できるチケットをアリスに返答する。この方式の利点として、アリスがボブだけではなく複数の主体と通信を行うときに AS との通信が一度だけで済む (通信相手の数だけ TGS と通信すれば済む) 点がある。
Kerberos が対象とするクライアント/サーバーアプリケーションの分野では、ある程度の正確さを持ったクロック同期が行えると仮定できる。このため Kerberos はタイムスタンプと寿命を利用でき、Needham-Shroeder 認証でノンスの利用から生じていたセキュリティ脆弱性を回避できる。また、Kerberos はハッシュ関数と秘密鍵暗号の切り替えをサポートし、最先端の暗号アルゴリズムを利用できるようになっている。