要約

  • RFC 3962 は PBKDF2 の反復回数を4バイトのビッグエンディアン符号なし整数で表し、明示的な全ゼロを4,294,967,296回、KDCが提示できた後の欠落を4,096回と定義した。
  • 偽の大きな値はクライアントを計算で止め、偽の小さな値は攻撃者の総当たりを安くする。必要だったのは一つの万能値ではなく、出所、真正性、上下限を分けた管理だった。

00 00 00 00 を整数へ変換する前に、受信処理にはもう一つの仕事がある。その4バイトが本当にメッセージに含まれていたかを記録することだ。RFC 3962 では、存在の有無が計算量を百万倍以上変える。

文字列から鍵を作るパラメーターは、4バイトのビッグエンディアン符号なし整数である。通常は PBKDF2 の反復回数をそのまま表す。ただし全ビットがゼロなら、意味はゼロ回ではなく4,294,967,296回、つまり (2^{32}) 回である。この規則によって表現可能な最小値は一回になった。

一方、KDC がパラメーターを渡せる状況なのにフィールド自体がなければ、00 00 10 00、十進数で4,096回を使う。この扱いは、すべてのレルムに推奨する既定値でも、楽観的事前認証で必ず選ぶ値でもない。特定の文脈における「欠落」の解釈にすぎない。

空欄をゼロで埋めると別の命令になる

フォーム、JSON、データベース、言語ランタイムは、空欄、null、長さゼロの配列、数値ゼロを便利にまとめがちである。この RFC では、その便利さがプロトコルを書き換える。欠落を全ゼロで補うだけで、4,096回が4,294,967,296回になる。存在フラグは周辺メタデータではなく、暗号処理の入力だった。

2005年2月に公開された RFC 3962 は、RFC 3961 の暗号プロファイルへ AES を組み込んだ。128ビットのブロック、128または256ビットの鍵、CBC暗号文窃取、HMAC-SHA1-96を定義し、暗号タイプ17と18、チェックサムタイプ15と16を割り当てた。現在の IANA Kerberos Parameters にも番号は残るが、登録はレルムでの有効化や実際の選択を証明しない。

パスワードとソルトは PBKDF2 に入り、一時鍵を作る。そこから RFC 3961 の導出処理が kerberos という定数を用いてプロトコル鍵を作る。RFC 2898 は当時の PBKDF2 仕様であり、RFC 8018 が後に PKCS #5 を改訂した。AES-256 の出力幅を、人間のパスワードが256ビットの予測不能性を持つ証拠にしてはならない。反復は一候補の試行費用を増やすが、入力にないエントロピーは作れない。

回数を上げても下げても攻撃になり得た

PBKDF2 の作業係数は公平である。辞書攻撃をする者だけでなく、正しいパスワードを入力した利用者にも同じ倍率を課す。RFC 3962 は反復回数を、攻撃者にだけ作用する防壁ではなく、双方の資源を考えて選ぶ費用倍率として扱った。

KDC の応答を偽装できる相手が極端に大きな値を送れば、クライアントは誤った鍵のために CPU を長時間使う。これはサービス拒否になる。実装は上限を設定でき、その上限を設けるなら50,000未満にすべきではない、と文書は述べた。全ゼロが示す四十億回以上の処理には、中断手段も現実的な制御になる。

極端に小さな値では、目的が逆になる。攻撃者はクライアントの応答を観測し、より安い費用でパスワード候補を試せる。そのため下限も必要になる。大きいほど常に安全という規則でも、ネットワークから来た値をそのまま信じる規則でも足りない。サイトの許容範囲と、値の出所の真正性が組みになって初めて判断できる。

ログに iterations=4096 だけがあっても、この判断は再現できない。認証済み KDC 応答か、保護されていないエラーか、キャッシュか、ローカル設定か、欠落規則かが分からないからだ。上限・下限の検査が計算より前だったかも必要である。同じ整数が、正規の政策にも、互換フォールバックにも、攻撃者入力にもなり得る。

楽観的事前認証は新鮮さを推測に置き換えた

楽観的事前認証では、クライアントが現在のパラメーターを KDC に聞く前に長期鍵を導出し、保護したタイムスタンプを送る。推測が当たれば往復を一つ減らせる。しかし追加情報がなければ、反復回数は推測しかない。

数時間前に同じプリンシパルで成功した値でさえ確実ではない。計算機性能に合わせてサイトが回数を増やすことを RFC 自身が想定していたからだ。文書は普遍的な一つの値を勧めず、受信値と同じ上下限の内側でサイトローカル設定を行うよう勧めた。

ここで歴史的なのは4,096や50,000という数字そのものではない。ハードウェアと攻撃費用は変わる。長く残るのは、値に所有者、観測時刻、更新経路が必要だという設計である。最新の KDC 観測を省く最適化には、それを代替する統治が要る。

鍵ができても認証は終わらない

PBKDF2 が完了して得られるのは鍵素材である。RFC 4120 が Kerberos V5 のチケット、認証子、リプレイ、プロトコル手順を定義する。導出成功だけでは、パスワードの正しさ、KDC の受理、チケットの有効性、アプリケーション認可、サービス提供のどれも証明しない。

RFC 4537 は提示された暗号タイプとサーバーが選んだタイプを分けた。RFC 6113 は事前認証とパラメーター運搬を一般化した。RFC 8009 は AES-CTS/HMAC-SHA2 を定義し、RFC 8429 は旧式アルゴリズムを非推奨にした。どの更新も、登録番号や導出結果を権限判断へ変えてはいない。

暗号文窃取には別の境界もある。パディングを増やさないため、暗号文長は平文長を正確に示す。長さを隠す必要があれば、上位層が別のデータを足さなければならない。PBKDF2 の回数を増やしても、この漏えいは直らない。

監査可能な記録には、フィールド存在、元の4バイト、解釈値、メッセージの出所と真正性、ローカル上下限、暗号タイプ、ソルトの由来、ライブラリ版、時間、資源、中断状態を含める。その後に事前認証、チケット、リプレイ検査、認可、サービス結果を別々に結ぶ。パスワードや秘密鍵そのものは記録しない。

RFC Editor の記録、IETF Datatracker、RFC 3962 の正誤表検索 は仕様履歴を示す。取得時に正誤表の該当項目はなかったが、それを実装全体の無欠陥証明にしてはならない。

RFC 3962 の教訓は巨大な回数よりも小さな区別にある。ゼロ、欠落、既定値は別の事実である。その差を保存できないシステムは、計算を誰が何の根拠で要求したかも保存できない。

出典