| 最新版 |
krb5-1.21.2
/ 2023年8月14日 |
|---|---|
| プログラミング 言語 | C |
| 対応OS | クロスプラットフォーム |
| 公式サイト |
web |
| インターネットセキュリティ プロトコル |
|---|
| キーマネジメント |
| アプリケーション層 |
| DNS |
| インターネット層 |
ケルベロス認証(ケルベロスにんしょう、Kerberos - )は、安全な方法で互いの身元を証明するために「チケット」を用いて動作するコンピュータネットワーク認証プロトコルである。シングルサインオンシステムを提供する。ケルベロス認証は1989年から使われている。
ケルベロス認証は、X Window Systemの開発で知られるマサチューセッツ工科大学 (MIT) のAthenaプロジェクトによって開発され、現在もMITで保守されている。その仕様はRFC 4120で標準化されている。
Kerberosは共通鍵暗号を基盤としており、信頼できる第三者(TTP)を必要とする。KerberosはデフォルトでUDPポート88を使用する。
マイクロソフトのActive Directoryでの推奨の認証機構となっている。また、macOSでは、Heimdalで実装されている。
名称はギリシャ神話おける地獄の番犬ケルベロスに由来し、日本ではギリシア語読みにならって「ケルベロス」とするが、英語では[ˈkərbərɒs](「カーバラス」に近い発音)となる。
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は暗号アルゴリズムとして共通鍵暗号および暗号文の改ざん対策としてのハッシュ関数のみを用い、公開鍵暗号には依存しないが、認証の特定のフェーズにおいて公開鍵暗号を使用することも可能である。
1980年代のマサチューセッツ工科大学 (MIT) にて研究プロジェクトとして始まった。MITのAthenaプロジェクトでは開始当初からクライアントサーバモデルを想定して設計されており、そのネットワーク認証のためにKerberosプロトコルが開発された。最初のバージョンは、主にSteve MillerとClifford Neumanによって設計され、初期のNeedham-Schroeder共通鍵プロトコルに基づいていた。この認証システムは、経路上での盗聴を防ぐために、認証サーバとその他のコンピュータとの間の認証のやりとりを暗号化している。
Kerberosバージョン3まではテストのために開発され、MIT内部でのみ使われた。そして、1989年1月24日に初めてMIT外部にKerberosバージョン4として公開される。Kerberosはいくつかのベンダーに採用されることとなった。
Kerberosバージョン4はDES(Data Encryption Standard)暗号化アルゴリズムを用いていたため、アメリカ政府の暗号化ソフトウェアに対する輸出規制に引っかかり、アメリカ国外の組織はMITから合法的にソフトウェアをダウンロードすることはできなかった。そのため、MITの開発チームは、Kerberosのソフトウェアから暗号化のコードをすべて取り除き骨格だけにし、輸出可能バージョンである「Bones」を作成した。オーストラリアのエリック・ヤングがこのBonesに独自のDES実装を追加した「eBones」を開発したことで、アメリカ国外でも合法的にKerberosバージョン4を使うことができるようになった。
その後、Kerberosバージョン4に機能を追加し、1993年に、AESやSHA-1等の追加によりセキュリティの強化を行ったバージョン5が開発される。Kerberosバージョン5のプロトコルはRFC 1510で文書化され、RFC 4120に置き換えられた。RFC 8009ではSHA-2が追加されている。
HeimdalはやはりDESの輸出規制を回避するため、スウェーデン王立工科大学(KTH)にて1997年から開発された。当初はKTH-KRBという名称で、エリック・ヤングのDES実装を使用していた。その後、DESの実装はHeimdal独自のものに置き換えられ、その際にライブラリ名がlibhcryptoへ変更されたことから、それまでに名称をHeimdalに改称したとみられる。
2005年、Internet Engineering Task Force (IETF) のKerberosワーキンググループは仕様を更新した。更新内容は以下の通りである。
MITは、BSDライセンスと同様の著作権許可の下で、Kerberosの実装を自由に利用できるようにしている。2007年、MITは開発の継続を促進するためにKerberosコンソーシアムを設立した。設立スポンサーには、Oracle、Apple、Google、マイクロソフト、Centrify Corporation、TeamF1 Inc.などのベンダーや、スウェーデン王立工科大学、スタンフォード大学、MITなどの学術機関が含まれており、CyberSafeなどのベンダーが商用サポート版を提供している。
Windows 2000およびそれ以降のバージョンでは、デフォルトの認証方法としてKerberosを使用している。Kerberosプロトコルスイートに対するマイクロソフトの追加機能の一部は、RFC 3244「Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols」に文書化されている。RFC 4757は、マイクロソフトによるRC4暗号の使用について文書化している。マイクロソフトはKerberosプロトコルを使用および拡張しているが、MITのソフトウェアは使用していない。
Kerberosは推奨される認証方法として使用されている。一般に、クライアントをWindowsドメインに参加させることは、そのクライアントからWindowsドメインおよびそのドメインと信頼関係にあるすべてのドメイン内のサービスへの認証において、Kerberosをデフォルトのプロトコルとして有効にすることを意味する。
対照的に、クライアントまたはサーバ、あるいはその両方がドメインに参加していない場合(または同じ信頼されたドメイン環境の一部ではない場合)、Windowsはクライアントとサーバ間の認証に代わりにNTLMを使用する。
インターネットWebアプリケーションは、SSPIで提供されるAPIを使用することで、ドメインに参加しているクライアントに対して認証方法としてKerberosを強制できる。
Microsoft WindowsおよびWindows Serverには、Active Directoryのサービスアカウントのサービスプリンシパル名 (SPN) を読み取り、変更、または削除するために使用できるコマンドラインユーティリティであるsetspnが含まれている。
FreeBSD、AppleのmacOS、Red Hat Enterprise Linux、OracleのSolaris、IBMのAIX、HP-UXなど、多くのUnix系オペレーティングシステムには、ユーザーまたはサービスのKerberos認証用ソフトウェアが含まれている。z/OS、IBM i、OpenVMSなどの非Unix系オペレーティングシステムもKerberosサポートを備えている。組み込みプラットフォーム上で動作するクライアントエージェントおよびネットワークサービスのためのKerberos V認証プロトコルの組み込み実装も、企業から入手可能である。
ケルベロス認証の鍵となるサービスアカウントのパスワードハッシュを盗み出し、TGTを自作する攻撃。攻撃が成功すると、パスワードを変更されても有効期限内は自由にネットワーク内を移動できてしまうため、ゴールデンチケットと呼ばれる。ゴールデンチケットを窃取する代表的なツールに、Mimikatzが存在する。Mimikatzはメモリ上の情報を取得し、盗んだ認証番号のうちパスワードなどを復号することにも使用する。
特定のファイルサーバーやデータベースなどのパスワードハッシュを盗み、そのサービス専用のチケットを偽造する攻撃。ドメインコントローラー(KDC)に問い合わせずに直接ターゲットサーバーへアクセスするため、ログに残りづらく検知が困難である。
正当なユーザーを装って入手したチケットの暗号に、オフラインで総当たりブルートフォース攻撃をして解読する手法。 特権を持つサービスアカウントのパスワードが短くて単純な場合、また、暗号方式がRC4の場合有効である。
メモリ上に保存されている他人の有効なチケットTGTやチケットを盗み出し、自分のセッションにインポートして、そのユーザーになりすます攻撃。パスワードそのものを知る必要がなく、一度ログインに成功した端末からさらに別の端末へ横展開する際に使われる。
Data Encryption Standard (DES) 暗号はKerberosと組み合わせて使用できるが、脆弱であるためもはやインターネット標準ではない。AESのような新しい暗号化方式をサポートしていないレガシーバージョンのKerberosを実装している製品には、セキュリティ上の脆弱性が存在する。