Kerberosが対称暗号化に基づいている理由はありますか？
Kerberos は、対称暗号のみを使用して構築された有名な認証プロトコルです。
この直接的な結果として、次のようないくつかの攻撃が可能です。
- AS-REPロースト
- AS-REQロースト
- ケルベロスト
- シルバーチケット
- ゴールデンチケット
一部の攻撃は特定の条件を必要としますが（AS-REPローストは事前認証を無効にする必要があります）、AS-REQローストなどの他の攻撃はまったく防止できません。
「これには非対称暗号を使用してください！」と叫ぶだけのタスクに対称暗号を使用するのは奇妙に思えます。何か足りないものはありますか？対称暗号を選択する理由は何ですか？
完全な開示：私はしばらくの間Kerberosを監督するプログラムマネージャーであり、現在マイクロソフトで積極的に取り組んでいる開発者です。
あなたが説明していることは厳密には正確ではありません。当初の仕様どおりのKerberosは、認証に対称暗号に依存しています。ただし、PKI認証のサポートを有効にし、クライアントの*ローストを無効にする、この仕様に対する広く使用されている拡張機能があります。たとえばWindowsでは、スマートカード認証とWindows HelloにPKINIT拡張機能を使用しています。
さらに、弱点は、シークレットが対称的であるということではなく、シークレットがユーザーによって生成されることが多いため、簡単に推測できるか、弱い暗号スイートを選択したことを意味します。非対称暗号ベースのプロトコルに切り替えると、問題は「キーを生成する方法」から「キーを保存および保護する方法」に移ります。実際には、どちらもさまざまな理由で同じように難しい問題です。
非対称キーは、ゴールデンチケットのような問題も解決しません。 krbtgt対称シークレットを盗む立場にいる場合、非対称シークレットを盗むのを阻止するものは何ですか？あまりありません。非対称鍵を保護する立場にある場合、対称鍵を保護する立場にないのはなぜですか？実際、今日の多くのシステムでは、パフォーマンス上の利点があるため、これらのタイプのトークン（セッションCookieやリフレッシュトークンなど）を保護するために対称シークレットを使用しています。非対称にしても、直接改善されるわけではありません（ただし、アプリのアーキテクチャによってそれ以外のことを指示される場合があります）。
サービスが秘密鍵を知る必要がないため、シルバーチケットの問題は非対称に移行することでメリットがあり、リークの可能性が減少します。
ただし、そうすることで相互認証の保証を放棄します。対称アルゴリズムには、両方の当事者が秘密を知っているため、相互認証があるという特性があります（システムは、複数の当事者がそれを知っている場合は一部を失います）。非対称キーでは、チケットを受け取る当事者が実際に彼らが言うとおりの人物である保証はありません。ここで、両方のパーティを明示的に認証する必要があります。これは、別の非対称キーを追加することで実行できますが、この交換で必要なキーの総数は少なくとも2倍になっています。あなたはまだ両側の秘密を守ることに行き詰まっています。
別のプロトコルへの切り替えの代替方法も、実際には達成が困難です。決して移動しないシステムがあり、移動するシステムは何年にもわたってそうします。これには、多くの標準化団体、ソフトウェア実装者、および企業を巻き込み、それらすべてを最善の方法で納得させることが必要です。それが不可能または悪い考えでさえあると言っているわけではありません。それを成功させるために必要な努力は莫大なものです。
あるいは、今日のKerberosの使用方法を少し調整して、本当に安全（tm）なセキュリティにすることもできます。
- Ditch Passwords（スマートカード、Windows Hello、FIDOなど）
- 強力に生成されたサービスアカウントパスワード（gMSAなど）を使用する
- 弱い暗号を無効にする（DES、RC4）
- 複合認証を有効にする（防御）