認証プロトコルの内部：Kerberos のチケットと公開鍵認証

Kerberos が解く問題：パスワードを使い回さずに何度もログインする

社内に数十のサービスがあるとき、サービスごとにパスワードを送って認証するのは危険です。送るたびに盗聴・リプレイの機会が増え、各サービスがパスワード（の検証材料）を持つことにもなります。Kerberos（RFC 4120）は、最初に1回だけ本人確認し、以降はパスワードを送らずに「チケット」で各サービスへ入ることでこれを解きます。これがドメイン環境のシングルサインオンの土台です。

中核にいるのが **KDC（Key Distribution Center＝鍵配布センター）**で、内部は2つの役割に分かれます。

• AS（Authentication Server）：本人確認を担当し、**TGT（Ticket-Granting Ticket）**を発行する。
• TGS（Ticket-Granting Server）：TGT を提示してきた相手に、個別サービス向けのサービスチケットを発行する。

Kerberos の信頼は対称鍵の共有に基づきます。各ユーザー・各サービスは、自分のパスワードや鍵から導いた長期鍵を KDC と共有しています。KDC はすべての長期鍵を知っているため、チケットの暗号化・検証を一手に引き受けられます。

3段階の発行フロー：AS → TGS → サービス

認証は3往復で進みます。鍵の流れを擬似コードで追います。表記の {X}_K は「X を鍵 K で暗号化したもの」、SK はセッション鍵です。

# 前提：ユーザー鍵 Kc（パスワード由来）、TGS鍵 Ktgs、サービス鍵 Ksvc
#       これらの長期鍵は KDC が全て保持している

# 1) AS Exchange（本人確認 → TGT 取得）
C -> AS : ユーザー名, 要求 TGT, クライアント現在時刻
AS -> C : {SK_tgs}_Kc,                      # ユーザー鍵で暗号化したセッション鍵
          TGT = {ユーザーID, SK_tgs, 期限}_Ktgs   # TGS だけが復号できる小包
# C はパスワードから Kc を導き {SK_tgs}_Kc を復号 → SK_tgs を得る
# TGT は中身を読めないまま保持する

# 2) TGS Exchange（TGT 提示 → サービスチケット取得）
C -> TGS : TGT, 利用したいサービス名,
           オーセンティケータ = {ユーザーID, タイムスタンプ}_SK_tgs
TGS -> C : {SK_svc}_SK_tgs,                  # 既存セッション鍵で暗号化
           ST = {ユーザーID, SK_svc, 期限}_Ksvc   # 対象サービスだけが復号できる

# 3) AP Exchange（サービスチケット提示 → サービス利用）
C -> Svc : ST, オーセンティケータ = {ユーザーID, タイムスタンプ}_SK_svc
Svc -> C : {タイムスタンプ+1}_SK_svc          # 相互認証（任意）

要点は3つです。第一に、パスワード由来の鍵 Kc を使うのは AS の1回だけで、以降は使い捨て寄りのセッション鍵 SK_tgs / SK_svc だけを使います。第二に、チケット（TGT・ST）は宛先の長期鍵で封がされているため、横取りしても中身を改竄できません。第三に、毎回オーセンティケータ（後述）を別添して「チケットの正規の持ち主であること」を示します。

チケットとオーセンティケータの役割分担

初学者が混乱しやすいのが、なぜチケットとは別に「オーセンティケータ」が要るのか、という点です。役割を分けて整理します。

チケットだけでは「正規に発行された許可証」を示せても、それを提示しているのが本物かは示せません。チケットは盗めばコピーできるからです。そこで、チケットに封じられたセッション鍵 SK でしか作れないオーセンティケータを毎回添えます。サービスはチケットを復号して SK を取り出し、その SK でオーセンティケータが正しく復号できれば「チケットの中の鍵を本当に持っている＝本物」と判定できます。これはメッセージ認証（HMAC）が「鍵を知る者しか作れないタグ」で真正性を示すのと同じ発想です。

タイムスタンプによるリプレイ対策

オーセンティケータにはクライアントの現在時刻が入ります。サービスは受け取ったタイムスタンプが「いまから許容幅（既定で前後5分）以内」かを検証し、範囲外なら拒否します。これにより、攻撃者が過去に盗んだオーセンティケータをあとで送り直すリプレイ攻撃が成立しなくなります。古いタイムスタンプは許容幅から外れて弾かれるためです。

ただしタイムスタンプだけでは「許容幅の5分以内に同じものを再送される」隙が残ります。そこでサービスはリプレイキャッシュを持ち、許容幅の間に見たオーセンティケータ（時刻＋送信元）を記録して、同一のものを二度受け付けません。

時刻同期を前提にすることで、Kerberos はノンス往復を増やさずに鮮度を保証できます。これが、チャレンジ・レスポンスを毎回やり取りする方式より往復が少ない理由でもあります。

Golden Ticket と Silver Ticket：鍵を盗めば偽造できる

Kerberos の安全性は「長期鍵が KDC とサービスだけの秘密である」ことに全面的に依存します。逆に言うと、その長期鍵が漏れると、攻撃者はKDC に一切問い合わせずに正規のチケットを自作できます。チケットは長期鍵で封じてあるだけなので、鍵を持つ者には偽造と正規の区別がつかないのです。これが Golden／Silver Ticket 攻撃の原理です。

# Golden Ticket：krbtgt の鍵を盗んだ場合
偽TGT = {任意のユーザーID（例: 管理者）, 任意の所属グループ, 長い有効期限, SK_tgs}_Krbtgt
# → AS をスキップして「最高権限の TGT」を自作。以後 TGS から
#    あらゆるサービスチケットを正規に発行させられる

# Silver Ticket：特定サービスの鍵を盗んだ場合
偽ST = {任意のユーザーID, 権限情報, SK_svc}_Ksvc
# → TGS もスキップ。そのサービス1つに対してだけ正規チケットを自作

Golden Ticket は krbtgt という KDC 内部アカウントの鍵を握る攻撃で、ドメイン全体を実質支配します。これを得るには通常、攻撃者がすでにドメイン管理者級まで侵害している必要があり、事後の永続化（バックドア）手段として悪用されるのが実態です。Silver Ticket は対象サービスの鍵だけで済むため範囲は狭い一方、TGS を経由しないのでKDC 側に通信記録が残らず、検知がより難しいのが厄介です。

補足：公開鍵認証（PKINIT）への拡張

ここまでは対称鍵（パスワード由来の鍵）が前提でしたが、AS Exchange の本人確認だけを公開鍵暗号に差し替える拡張が **PKINIT（Public Key Cryptography for Initial Authentication）**です。ユーザーは AS への最初の要求を、自分の証明書に対応する秘密鍵で署名して送り、AS はPKIで証明書を検証します。スマートカードや証明書ベースのログインがこれにあたります。

重要なのは、PKINIT が置き換えるのは AS の初回認証だけで、TGT 取得以降の TGS／AP Exchange は従来どおり対称鍵のチケットで動く点です。公開鍵処理はログイン時の1回に限定し、以降の高頻度なやり取りは軽量な対称鍵で回す——この役割分担が Kerberos の設計の一貫した狙いです。

# PKINIT：AS Exchange の本人確認だけを公開鍵に置換
C -> AS : 要求, クライアント証明書, {タイムスタンプ}_秘密鍵（署名）
AS      : 証明書を PKI で検証 → 本人確認 OK
AS -> C : セッション鍵（公開鍵で配送）, TGT = {...}_Ktgs
# ↓ ここから先は通常の Kerberos（対称鍵チケット）と完全に同じ

まとめると、Kerberos は「最初の1回だけ本人確認し、以降はチケットで回す」設計を、対称鍵・チケット・オーセンティケータ・タイムスタンプの組み合わせで実現しています。安全性は長期鍵の秘匿に依存し、そこが破られると Golden／Silver Ticket として牙をむきます。認証と認可の役割分担は認証と認可の違い、パスワード以外の要素を足す考え方は多要素認証（MFA）も合わせて押さえると、全体像がつながります。