Kerberos 入門
はじめに
本記事では、基本的なKerberosの概念や動作概要について紹介します。次回執筆予定のKerberosに対するペネトレーションテストの記事を理解するために必要な知識をまとめています。Kerberosは一見複雑そうに見えるプロトコルですが、Kerberos用語などを理解すると動作内容がとても明快でシンプルなことがわかります。そこで、まずは知らない用語も含まれてきてしまうかもしれませんが、基本用語を始めに記載しました。まずは、ここに目を通していただいてから、動作概要を見ていただくのが良いかと思います。筆者自身もKerberosについて深い理解があるわけではなく勉強がてらまとめているので間違いなどありましたら、Twitterなどでご指摘いただけると幸いです。
Kerberosとは
Kerberosは、パスワードがネットワーク上を流れる箇所を減らし、代わりにチケットと呼ばれる暗号化されたデータを用いて、各種サービスを利用する仕組みを提供するプロトコルです。Kerberosには、大きく分けて3つのバージョンの括りが存在します。バージョン1,2,3はテストの目的で作られMITの内部でのみ使われていました。MITが最初に外部に配布したのがバージョン4です。しかしながら、バージョン4ではDES暗号を使っており、当時のアメリカ合衆国政府が課した暗号化ソフトウェアに対する輸出規制のためアメリカ合衆国以外へ輸出することができませんでした(そのため、MITの開発チームは、Kerberosからすべての暗号化コードを抜いた輸出可能なBonesというソフトウェアを構築しました)。そして、現在主流となるのがバージョン5です。バージョン4では提供されなかった機能の追加やセキュリティの強化を目的として開発されました。今日ではKerberosは、MicrosoftのActive Directoryなどにも採用されており企業ネットワークでは非常に重要な存在になっています。
基本用語
- レルム(REALM)
- Kerberosにおける管理対象となる論理的なネットワーク
- レルム名には、**DNSのドメイン名(大文字)**が利用されることが多い
- 例)
ALICEMACS.COM
- 例)
- プリンシパル(PRINCIPAL)
- Kerberosから認識されるユーザ、サービスやホストのこと
- ユーザプリンシパル、サービスプリンシパル(SPN)、ホストプリンシパルの3つに大別される
- プリンシパル名と呼ばれる一意な名前を利用する(
[]
内はオプション項目)username[/instance]@REALM
(instanceは、ホスト名)service[/FQDN]@REALM
(ホストプリンシパルの場合、serviceが"host"
という固定文字列になる)
- Kerberosから認識されるユーザ、サービスやホストのこと
- サービスサーバ(SS: Service Server)
- Kerberos対応したサービスを提供するサーバ
- サービスチケット(ST: Service Ticket)
- サービスの利用するためにクライアントがサービスサーバに送信するチケット
- チケット交付チケット(TGT: Ticket Granting Ticket)
- サービスチケットを要求するために利用されるチケット
- 認証サーバ(AS: Authentication Server)
- クライアントに、暗号化されたTGTを発行する
- この暗号化には、クライアントのパスワードが利用されるため本人でないと復号できない
- チケット交付サーバ(TGS: Ticket Granting Server)
- サービスチケットをクライアントに発行する
- 鍵配布センター(KDC: Key Distribution Center)
- 以下の3つの要素から構成される
- すべてのプリンシパルと関連する暗号化鍵のデータベース
- 認証サーバ
- チケット交付サーバ
- 1つのレルムには少なくとも1つの鍵配布センターが必要
- 以下の3つの要素から構成される
動作概要
ここでは、例としてあるユーザがクライアントからKerberos対応したサービスを利用するまでの流れを見ていきます。初めに以降に説明する流れを簡単に図示したものを示します。適宜、この図を見返しながら読むとわかりやすいかもしれません。
1. ユーザのログインと鍵生成
まず初めにユーザは、クライアントに自身のユーザIDとパスワードを使ってログインします。これによりKerberos対応しているクライアントは、パスワードを用いて共通鍵暗号の鍵を生成します(この変換処理のことを一般にstrings2Key
と呼びます)。この鍵のことを便宜上「クライアントの鍵」と定義しておきます。鍵を生成したらクライアントはTGTを取得する処理に移ります。
2. TGTの取得
TGTを取得したいクライアントは、ASに対して**AS_REQ(Authentication Server REQuest)**と呼ばれるリクエストを送信します。AS_REQでは、主に以下の3つの情報を送信します。
- クライアントのプリンシパル名
- クライアントのタイムスタンプ
- TGSのプリンシパル名
1つ目のクライアントのプリンシパル名とは、ユーザプリンシパル名やWindowsの場合SAMアカウント名が利用されます。2つ目のタイムスタンプは、各プリンシパルやKDCでの時刻がずれていないかを確認するために利用されます。最後のTGSのプリンシパル名は、krbtgt/FQDN@REALM
で固定されています(Kerberos 5の場合)。これは、krbtgtのSPNと言い換えることもできます。
ASは、この要求を受け取ると上述したクライアントプリンシパルが存在することとタイムスタンプがKDCのローカルタイムとずれていないこと(通常5分以内)を確認します。問題がなければ、ASはクライアントとTGS間のセッション鍵を生成します。この鍵のことを便宜上「クライアント/TGSセッション鍵」と定義しておきます。そしてASは以下の2つの情報を含む**AS_REP(Authentication Server REsPonse)**と呼ばれるレスポンスを行います。
- 「クライアントの鍵」を利用して暗号化された「クライアント/TGSセッション鍵」
- TGSが持つ鍵で暗号化されたTGT(以下の情報を含む)
- クライアントのプリンシパル名
- クライアントのIPアドレス
- チケットの有効期限
- クライアント/TGSセッション鍵
クライアントは、上記2つの情報を受取ると自身が持つ「クライアントの鍵」を用いて「クライアント/TGSセッション鍵」を復号します。これにより、クライアントはTGSと通信を行う際に暗号化したデータで送受信することができるようになります。しかしながら、TGTはTGSのみが保つ鍵で暗号化されているためクライアントは復号することができません。
次にクライアントは、TGSから利用したいサービスのSTを取得する処理に移ります。
3. STの取得
クライアントは、TGSに対して、「このサービスを利用するためのチケットを取得したい」というリクエストを送信します。このリクエストは、TGS_REQ
と呼ばれます。このリクエストを行う際には、以下の3つ情報を送信します。
- TGSが持つ鍵で暗号化されたTGT
- アクセスしたいサービスのSPN
- 「クライアント/TGSセッション鍵」で暗号化されたAuthenticator(Authenticatorには以下の情報を含む)
- クライアントのプリンシパル名
- クライアントのタイムスタンプ
TGSはこれらの情報を受け取ると、初めに暗号化されたTGTを復号します。送られてくるTGTは、TGSが持つ鍵で暗号化されているため復号できます。TGTを復号できるとTGSは、「クライアント/TGSセッション鍵」を手に入れることができます。そのため手に入れたセッション鍵を用いて、受け取った暗号化されているAuthenticatorを復号します。これにより判明したクライアントのプリンシパル名と復号したTGTに記載されているクライアントのプリンシパル名を比較して一致することを確認します。問題がなければ、以下の2つの情報をクライアントにレスポンスします。このレスポンスのことをTGS_REP
と呼びます。
- SSが持つ鍵で暗号化されたST(STには以下の情報を含む)
- クライアントのプリンシパル名
- クライアントのIPアドレス
- チケットの有効期限
- クライアント/SSのセッション鍵
- 「クライアント/TGSセッション鍵」で暗号化された「クライアント/SSセッション鍵」
これらを受け取ったクライアントは、Kerberos対応されたサービスの利用のリクエストを行うことが出来るようになりました。最後にクライアントがSTを用いて、当該サービスを利用する処理に移ります。
4. サービスの利用
クライアントが、サービスを利用するためにリクエストを行う際に送信する情報は以下の2つです。
- ST
- 「クライアント/SSセッション鍵」で暗号化されたAuthenticator(含む情報は上述したものと同じ)
これらを受け取ったSSは、STを復号します。送られてくるSTは、SSが持つ鍵で暗号化されているため復号できます。SSは、STを復号すると「クライアント/SSセッション鍵」を手に入れることができるので、Authenticatorを復号できるようになります。そこでこれを復号し、受け取った2つの情報が復号できると、TGSの時と同じようにそれぞれに格納されているクライアントのプリンシパル名を確認します。これが一致する場合、サービス提供サーバはクライアントに対してAuthenticatorに含まれるタイムスタンプを「クライアント/SSセッション鍵」で暗号化してクライアントにレスポンスします。そしてこれを受け取ったクライアントは、タイムスタンプを復号し正常な時間かどうかを確認します。正常であれば、その後クライアントはSSへサービスの要求を開始し利用することができるようになります。
おわりに
本記事では、Kerberosを用いてクライアントがサービスを利用するまでの流れを詳細に見てきました。大雑把にまとめてしまうとKerberosは、ユーザが一度ログインしてしまえば、ある一定期間はログイン済みであることを証明するTGTと呼ばれるチケットを用いて、各種サービスへのアクセスを要求し、当該サービスを利用するためのチケットを取得することで利用できるようになるシステムです。次回の記事では、本記事の知識を前提にKerberosにおける攻撃手法を解説します。