KERBEROSとは？ わかりやすく解説

「Kerberos」はこの項目へ転送されています。その他の用法については「ケルベロス (曖昧さ回避)」をご覧ください。

ケルベロス認証（ケルベロスにんしょう、Kerberos - ）は、安全な方法で互いの身元を証明するために「チケット」を用いて動作するコンピュータネットワーク認証プロトコルである^[2]。シングルサインオンシステムを提供する^[3]。ケルベロス認証は1989年から使われている^[3]。

ケルベロス認証は、X Window Systemの開発で知られるマサチューセッツ工科大学 (MIT) のAthenaプロジェクトによって開発され、現在もMITで保守されている。その仕様は RFC 4120 で標準化されている。

Kerberosは共通鍵暗号を基盤としており、信頼できる第三者（TTP）を必要とする。KerberosはデフォルトでUDPポート88を使用する。

マイクロソフトのActive Directoryでの推奨の認証機構となっている^[3]。また、macOSでは、Heimdalで実装されている^[4]。

名称はギリシャ神話おける地獄の番犬ケルベロスに由来し^[5]、日本ではギリシア語読みにならって「ケルベロス」とするが、英語では[ˈkərbərɒs]（「カーバラス」に近い発音^[6]）となる。

Kerberos サーバーを運用したい組織は、独自の 「レルム」を構築する。レルムは、ユーザーや認証の範囲を示す。レルムに属するマシンやサービスはプリンシパルと呼ばれる。レルムにはKDC（key distribution center、直訳：鍵配送センター）と呼ばれる権限者が存在する。KDCはAS（Authentication Server、直訳：認証サーバ）というサーバとTGS（Ticket Granting Server、意訳：チケット発行許諾サーバ）の2要素から構成され、通常は一体として運用される。

各プリンシパルは所属するレルムのKDCを直接信頼し、その証拠としてKDCとの間で共通鍵を共有する。プリンシパルとKDC間で送受信するメッセージはこの共通鍵で暗号化することにより、メッセージの認証および秘匿性を実装する。一方、プリンシパル同士が直接メッセージを生成して送受信することはなく、プリンシパル同士の信頼はKDCが生成するメッセージを通じて推移的に確立する。

ユーザがレルムにログインする際には、まず自身の持つクライアント端末からID/パスワードなどで認証を受け、認証が受理されたらクライアント端末はこのパスワードを利用して秘密鍵Kを生成する。クライアントはユーザのIDを平文でASに送り、ASはユーザのIDを自身のデータベースに問い合わせる事でユーザの秘密鍵Kを得る。

次にASはTGT（ticket-granting ticket、意訳：チケット発行許諾チケット）と、クライアント/TGSセッション鍵とをKで共通鍵暗号化してクライアント端末とTGSに送る。ユーザがTGSから「チケット」というデータを受け取るための大元となるチケットがTGTであり、クライアント/TGSセッション鍵はTGSからチケットを受け取る際に用いるセッション鍵である。なお、共通鍵暗号としては、バージョン4においては56bitDES暗号を用いる。

その後ユーザがレルム内にあるプリンシパルAが提供しているサービスを利用したくなったら、ユーザのクライアント端末はTGTをAのサービスを使いたい旨とともにTGSに送る。具体的には、クライアントはサービスプリンシパル (SPN) を使用して、TGSに登録されている特定のサービスへのアクセスを要求する。

この際の通信はクライアント/TGSセッション鍵で共通鍵暗号化しておく。TGSはTGTの正当性を確認し、チケットという、Aのサービスを利用する許可証をクライアント端末に送り、さらにAとの通信で用いるセッション鍵もクライアント端末に送る。

チケットに記載された有効期限内にチケットを（セッション鍵で暗号化して）プリンシパルAに送れば、クライアント端末はAの提供するサービスを利用できる。このとき、サービス利用を開始する前に、クライアントはサーバーが偽物でないかを確認を行う。 サーバーは、自身の正当性を示すために、クライアントから受け取ったタイムスタンプを「セッション鍵」で暗号化して送り返す。クライアントがこれを正しく復号して時刻を確認できた場合のみ、サーバーを信頼し、通信を開始する（これを相互認証と呼ぶ）。

以上のように、ユーザがID/パスワードを使うのは最初にASから認証を受ける時だけであり、とても少ない。（以後はTGTを使ってTGSから認証を受ける。）そうすることでID/パスワードの漏洩を防いでいる。

また、TGTを直接プリンシパルAに送ってしまうと、AがTGTを使ってユーザになりすまして別のプリンシパルのサービスを利用できてしまうため、クライアント端末がTGTを直接プリンシパルAに送信する事はしない。その代わりに、TGSにTGTを送ることでAへのアクセスのみに利用できるチケットを発行してもらい、このチケットでAの認証を受け、サービスを利用する。

Kerberosは暗号アルゴリズムとして共通鍵暗号および暗号文の改ざん対策としてのハッシュ関数のみを用い、公開鍵暗号には依存しないが、認証の特定のフェーズにおいて公開鍵暗号を使用することも可能である^[2]。

1980年代のマサチューセッツ工科大学 (MIT) にて研究プロジェクトとして始まった^[7]。MITのAthenaプロジェクトでは開始当初からクライアントサーバモデルを想定して設計されており、そのネットワーク認証のためにKerberosプロトコルが開発された^[8][9]。最初のバージョンは、主にSteve MillerとClifford Neumanによって設計され、初期のNeedham-Schroeder共通鍵プロトコルに基づいていた^[10][11]。この認証システムは、経路上での盗聴を防ぐために、認証サーバとその他のコンピュータとの間の認証のやりとりを暗号化している^[8]。

Kerberosバージョン3まではテストのために開発され、MIT内部でのみ使われた^[12]。そして、1989年1月24日に初めてMIT外部にKerberosバージョン4として公開される^[12]。Kerberosはいくつかのベンダーに採用されることとなった^[12]。

Kerberosバージョン4はDES（Data Encryption Standard）暗号化アルゴリズムを用いていたため、アメリカ政府の暗号化ソフトウェアに対する輸出規制に引っかかり、アメリカ国外の組織はMITから合法的にソフトウェアをダウンロードすることはできなかった^[13]。そのため、MITの開発チームは、Kerberosのソフトウェアから暗号化のコードをすべて取り除き骨格だけにし、輸出可能バージョンである「Bones」を作成した^[14]。オーストラリアのエリック・ヤングがこのBonesに独自のDES実装を追加した「eBones」を開発したことで、アメリカ国外でも合法的にKerberosバージョン4を使うことができるようになった^[14]。

その後、Kerberosバージョン4に機能を追加し、1993年に、AESやSHA-1等の追加によりセキュリティの強化を行ったバージョン5が開発される^[14]。Kerberosバージョン5のプロトコルは RFC 1510 で文書化され、 RFC 4120 に置き換えられた^[14]。 RFC 8009 ではSHA-2が追加されている。

HeimdalはやはりDESの輸出規制を回避するため、スウェーデン王立工科大学（KTH）にて1997年から開発された。^[15][16]当初はKTH-KRBという名称で、エリック･ヤングのDES実装を使用していた。その後、DESの実装はHeimdal独自のものに置き換えられ、その際にライブラリ名がlibhcryptoへ変更されたことから、それまでに名称をHeimdalに改称したとみられる。

2005年、Internet Engineering Task Force (IETF) のKerberosワーキンググループは仕様を更新した。更新内容は以下の通りである。

• 暗号化およびチェックサム仕様 (RFC 3961)
• Kerberos 5のためのAdvanced Encryption Standard (AES) 暗号化 (RFC 3962)
• Kerberos V5仕様の新版「The Kerberos Network Authentication Service (V5)」 (RFC 4120)。このバージョンはRFC 1510を廃止し、プロトコルの側面と意図された使用法について、より詳細かつ明確な説明を加えたものである。
• Generic Security Services Application Program Interface (GSS-API) 仕様の新版「The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2」 (RFC 4121)

MITは、BSDライセンスと同様の著作権許可の下で、Kerberosの実装を自由に利用できるようにしている。2007年、MITは開発の継続を促進するためにKerberosコンソーシアムを設立した。設立スポンサーには、Oracle、Apple、Google、マイクロソフト、Centrify Corporation、TeamF1 Inc.などのベンダーや、スウェーデン王立工科大学、スタンフォード大学、MITなどの学術機関が含まれており、CyberSafeなどのベンダーが商用サポート版を提供している。

Windows 2000およびそれ以降のバージョンでは、デフォルトの認証方法としてKerberosを使用している^[17]。Kerberosプロトコルスイートに対するマイクロソフトの追加機能の一部は、RFC 3244「Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols」に文書化されている。RFC 4757は、マイクロソフトによるRC4暗号の使用について文書化している。マイクロソフトはKerberosプロトコルを使用および拡張しているが、MITのソフトウェアは使用していない。

Kerberosは推奨される認証方法として使用されている。一般に、クライアントをWindowsドメインに参加させることは、そのクライアントからWindowsドメインおよびそのドメインと信頼関係にあるすべてのドメイン内のサービスへの認証において、Kerberosをデフォルトのプロトコルとして有効にすることを意味する^[17]。

対照的に、クライアントまたはサーバ、あるいはその両方がドメインに参加していない場合（または同じ信頼されたドメイン環境の一部ではない場合）、Windowsはクライアントとサーバ間の認証に代わりにNTLMを使用する^[17]。

インターネットWebアプリケーションは、SSPIで提供されるAPIを使用することで、ドメインに参加しているクライアントに対して認証方法としてKerberosを強制できる。

Microsoft WindowsおよびWindows Serverには、Active Directoryのサービスアカウントのサービスプリンシパル名 (SPN) を読み取り、変更、または削除するために使用できるコマンドラインユーティリティであるsetspnが含まれている^[18][19]。

FreeBSD、AppleのmacOS、Red Hat Enterprise Linux、OracleのSolaris、IBMのAIX、HP-UXなど、多くのUnix系オペレーティングシステムには、ユーザーまたはサービスのKerberos認証用ソフトウェアが含まれている。z/OS、IBM i、OpenVMSなどの非Unix系オペレーティングシステムもKerberosサポートを備えている。組み込みプラットフォーム上で動作するクライアントエージェントおよびネットワークサービスのためのKerberos V認証プロトコルの組み込み実装も、企業から入手可能である。

• Kerberosには厳密な時間要件があり、関与するホストの時計は構成された制限内で同期されている必要がある。チケットには利用可能な期間があり、ホストの時計がKerberosサーバの時計と同期していない場合、認証は失敗する。MITによるデフォルト構成では、時計のズレが5分以内であることが要求される。実際には、ホストの時計を同期させるために通常はNetwork Time Protocolデーモンが使用される。一部のサーバ（マイクロソフトの実装など）は、両方の時計のオフセットが構成された最大値を超えている場合、暗号化されたサーバ時刻を含むKRB_AP_ERR_SKEW結果を返す場合があることに注意が必要である。その場合、クライアントは提供されたサーバ時刻を使用してオフセットを見つけ、時間を計算して再試行することができる。この動作はRFC 4430に文書化されている。
• 管理プロトコルは標準化されておらず、サーバの実装によって異なる。パスワードの変更はRFC 3244に記載されている。
• 共通鍵暗号を採用する場合（Kerberosは共通鍵または非対称（公開鍵）暗号を使用して動作可能）、すべての認証は一元化された鍵配布センター (KDC) によって制御されるため、この認証インフラストラクチャが侵害されると、攻撃者は任意のユーザーになりすますことが可能になる。
• 異なるホスト名を必要とする各ネットワークサービスには、独自のKerberosキーセットが必要となる。これは、バーチャルホスティングやクラスタを複雑にする。
• Kerberosでは、ユーザーアカウントとサービスがKerberosトークンサーバに対して信頼関係を持っている必要がある。
• クライアントの信頼が必要となるため、ステージング環境（例：テスト環境、プレ本番環境、本番環境のための個別のドメイン）の作成が困難になる。環境ドメインの厳密な分離を妨げるドメイン信頼関係を作成するか、各環境用に追加のユーザークライアントを提供する必要がある。

ケルベロス認証の鍵となるサービスアカウントのパスワードハッシュを盗み出し、TGTを自作する攻撃。攻撃が成功すると、パスワードを変更されても有効期限内は自由にネットワーク内を移動できてしまうため、ゴールデンチケットと呼ばれる^[20]。

特定のファイルサーバーやデータベースなどのパスワードハッシュを盗み、そのサービス専用のチケットを偽造する攻撃です。ドメインコントローラー（KDC）に問い合わせずに直接ターゲットサーバーへアクセスするため、ログに残りづらく検知が困難である^[21]。

正当なユーザーを装って入手したチケットの暗号に、オフラインで総当たりブルートフォース攻撃をして解読する手法^[22]。 特権を持つサービスアカウントのパスワードが短くて単純な場合、また、暗号方式がRC4の場合有効である。

メモリ上に保存されている他人の有効なチケットTGTやチケットを盗み出し、自分のセッションにインポートして、そのユーザーになりすます攻撃。パスワードそのものを知る必要がなく、一度ログインに成功した端末からさらに別の端末へ横展開する際に使われる^[23]。

Data Encryption Standard (DES) 暗号はKerberosと組み合わせて使用できるが、脆弱であるためもはやインターネット標準ではない^[24]。AESのような新しい暗号化方式をサポートしていないレガシーバージョンのKerberosを実装している製品には、セキュリティ上の脆弱性が存在する。

• RFC 1510 The Kerberos Network Authentication Service (V5) [廃止]
• RFC 1964 The Kerberos Version 5 GSS-API Mechanism
• RFC 3961 Encryption and Checksum Specifications for Kerberos 5
• RFC 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5
• RFC 4120 The Kerberos Network Authentication Service (V5) [現在]
• RFC 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
• RFC 4537 Kerberos Cryptosystem Negotiation Extension
• RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows [廃止]
• RFC 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
• RFC 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
• RFC 5868 Problem Statement on the Cross-Realm Operation of Kerberos
• RFC 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy
• RFC 6111 Additional Kerberos Naming Constraints
• RFC 6112 Anonymity Support for Kerberos
• RFC 6113 A Generalized Framework for Kerberos Pre-Authentication
• RFC 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
• RFC 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message
• RFC 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
• RFC 6560 One-Time Password (OTP) Pre-Authentication
• RFC 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
• RFC 6784 Kerberos Options for DHCPv6
• RFC 6803 Camellia Encryption for Kerberos 5
• RFC 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals
• RFC 6880 An Information Model for Kerberos Version 5
• RFC 8009 AES Encryption with HMAC-SHA2 for Kerberos 5

• シングルサインオン
• アイデンティティ管理
• Kerberoasting

ウィキメディア・コモンズには、ケルベロス認証に関連するメディアがあります。

• MITのページ
• RFC 1510: Kerberos ネットワーク認証サービス v5
• Kerberos FAQ v2.0 2000/8/18執筆時点。

この項目は、ソフトウェアに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

• 表示
• 編集