要約

  • RFC 1938では、提出値を一回ハッシュした結果が保存済み検証値と一致すれば受理し、直後に提出値そのものを次の検証値として保存した。
  • したがって成功は読み取りではなく、順序を持つ状態遷移である。同じ応答が並行処理で二度成功しないことまでが認証の意味に含まれる。
  • 秘密のパスフレーズは回線に流れないが、後続セッションの暗号化や能動攻撃への一般的防御にはならない。HOTPとTOTPは別の移動状態を選んだ。

受理された正解は、その場で消費される

二つの端末が、同じ有効な応答をほぼ同時に送ったとする。再利用型パスワードなら両方の照合が真になり得る。しかしRFC 1938の仕組みでは、先に完了した一件だけが境界を越えるべきである。最初の成功がサーバー記録を書き換えた後、二件目は文字列が同じでも、もはや同じ証明ではない。

RFC Editorの現行記録によれば、N. HallerとC. MetzによるこのProposed Standardは1996年5月に公開され、現在はRFC 2289によって廃止されている。だが重要なのは状態ラベルより、「ワンタイム」という名称の下で何が書き換わったかだ。

利用者は秘密のパスフレーズと、秘密でないseedを使う。生成器は両者を混ぜ、単方向ハッシュを反復する。深さNから始めるなら、最初の応答は遠端のH^N(S)、次は一段戻ったH^(N-1)(S)である。サーバーはパスフレーズを保存せず、直前の64ビット検証値とシーケンス位置を持つ。

値xを受け取るとH(x)を計算し、保存値と等しければ受理する。そしてxを新しい保存値にする。「比較」より「置換」が本質だ。xを後で再送しても、H(x)が到達するのは消去済みの古い参照値であり、現在のxとは一致しない。時間が勝手にパスワードを失効させるのではなく、成功が次の判定世界を変更する。

この構造は、BellcoreのS/KEYを記録したRFC 1760から発展した。狙いは限定的で実務的だった。盗聴できるネットワークを介してログインすると、再利用型パスワードは一度の観察を長期的な鍵に変えてしまう。ハッシュ連鎖なら秘密のパスフレーズを送らず、傍受された今回の応答も状態更新後には使えなくなる。

六語は秘密の文章ではない

チャレンジはアルゴリズム、シーケンス、seedを otp-md5 487 dog2 のように示す。RFC 1938ではMD5が必須、SHAが推奨、MD4が任意だった。生成側と検証側の一致が必要であり、弱い選択肢を残せば、それが安全性の下限になり得る。

64ビットの値は人が正確に入力しにくい。そこで2,048語の標準辞書から六語を選ぶ。各語が11ビットを担い、計66ビットとなる余分な2ビットは入力・復号誤りを検出するチェックサムだ。打ち間違いの発見には役立つが、別の本人確認ではない。単語の意味が秘密を増やすわけでもない。

サーバーは標準六語形式と16進形式を受理し、代替辞書形式も受け入れることが推奨された。大文字小文字、辞書、復号、正規化は見た目の問題ではなく相互運用経路にある。同じ64ビットを別物にしてしまう処理は、正しい計算を入口で壊す。

暗号が正しくても、取引順序は壊れる

RFC 1938は能動的な競合も挙げる。攻撃者が六語の大半を聞き、残りを推測して正規利用者より先に送る場面だ。準拠サーバーには防御が必要で、同一利用者の認証セッションを並行させない方法が示された。ただしタイムアウトも必要である。ロック自体が恒久的なサービス拒否になってはならない。

サーバー内部でも同じ問題が起きる。二つの処理が同じ古い検証値を読み、同じxをそれぞれ有効と判断してから書き込めば、一回だけ消費できる証明が二つの成功を生む。ハッシュ関数は間違っていない。compare-and-advanceが原子的でないのだ。並行性は実装上の後片付けではなく、プロトコルが作ろうとする真実を決める。

連鎖には終端がある。シーケンス番号は残りの認証在庫を表す。再初期化ではseedかパスフレーズを変えなければならない。両方を再利用すると、すでに観察された可能性のある連鎖を再生する。修復のために秘密パスフレーズを平文送信すれば、設計目的そのものが崩れる。

推奨手順には興味深い端点もある。新しい連鎖を登録する権限確認として古いOTPを要求できるが、カウント1で最後の応答をログインに使うと、更新を承認する次の応答が残らない。ゼロになる前に動く運用が必要であり、可用性は認証状態の内側にある。

後継仕様と、異なる移動因子

RFC 2289の記録は1998年のProposed Standardを示す。後継本文は下降連鎖を維持しつつ、テストベクトルや運用上の注意を充実させた。TCP接続ハイジャックなどへの対策としてIPsecを推奨する点は、OTPとセッション保護を分けて考える理由になる。ログインが正しくても通信路は自動的に安全にならない。

後の方式は別の場所に変化を置いた。HOTPは共有秘密と増加カウンターを使い、検証側は先読み窓で再同期し、成功後にカウンターを進める。TOTPはHOTPの移動因子を時間ステップにし、同じ時間ステップで成功済みのOTPを再受理しないよう求める。比較はできるが、S/KEYから派生したとの証拠にはならない。秘密の置き場所、進行方向、同期問題が異なる。

それでも三者は共通の問いを残す。値が一致するかだけでなく、どの状態が現在か、どの近傍まで許すか、成功が何を消費するか、複数検証器がどう合意するか。認証は暗号と変更統治の接点である。

主張の範囲も限定される。RFC 1938は通信の秘匿を提供せず、能動攻撃やソーシャルエンジニアリング一般を防がない。受理は応答が設定済みアカウントの現在状態に適合したことを示すだけで、コマンドの権限、後続セッションの機密性、処理完了、継続アクセス、端末前の人物の法的身元まで証明しない。

名称の下にある現実

Heng LuのRunning-Code Primacyを当てると、仕様の動詞と実装の差が見える。「一度進める」と書くのは簡単だが、障害後も更新が残るか、複製が同じ順序を見るか、リセットが古い再送路を復活させないかは稼働証拠でしか確認できない。

最小初期仕様として必要なのは巨大な製品設計ではない。連鎖、チャレンジ、表現、受理条件、状態前進という小さな共通核である。地域ごとの実装差は許せても、一つの消費可能な応答を二つの成功に変える差は許せない。

現実の層を分ければ、「ワンタイム」は象徴的な呼称にすぎない。運用上の実体は保存検証値、原子的置換、競合方針、有限連鎖、管理された再初期化である。層がずれれば、計算上は正しくても歴史上は誤りとなり、「一度」と名付けた応答が二度通る。

RFC 1938の深い遺産は、コードが変わること自体ではない。証明の成功が、次の証明を判断する世界を変えることだ。そのとき成功は読み取りではない。所有者と順序を定め、記録を残すべき書き込みになる。

出典

  1. RFC Editor — RFC 1938の現行記録
  2. RFC 1938 — A One-Time Password System
  3. RFC 1760 — The S/KEY One-Time Password System
  4. RFC Editor — RFC 2289の現行記録
  5. RFC 2289 — A One-Time Password System
  6. RFC 4226 — HOTP
  7. RFC 6238 — TOTP
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile