TOTP/HOTP の内部動作（時刻同期ワンタイムパスワードの数理）

ワンタイムパスワードが解こうとしている問題

認証アプリに表示される6桁コードは、毎回違う「使い捨ての秘密」です。狙いは、ネットワークを流れる認証情報を再利用不能にすること。固定パスワードは盗聴・流出すれば何度でも悪用されますが、ワンタイムパスワード（OTP）は一度使えば（あるいは一定時間で）無効になるため、傍受してもリプレイできません。これが多要素認証の「所持」要素として OTP が広く使われる理由です（要素の組み合わせは 多要素認証（MFA） を参照）。

OTP には大きくチャレンジ・レスポンス型と同期型がありますが、認証アプリが採るのは同期型です。サーバーと端末が共有秘密を一度だけ交換しておき、以後は通信なしで同じコードを独立に計算して照合します。鍵となる発想は「共有秘密と、双方が一致させられるカウンタ（イベント回数や現在時刻）を、鍵付きハッシュに通す」こと。HOTP がイベント版、TOTP が時刻版です。

HOTP：カウンタを HMAC に通す（RFC 4226）

**HOTP（HMAC-based One-Time Password, RFC 4226）**は、すべての OTP の土台です。入力は二つだけ。K（端末とサーバーが共有する秘密鍵、通常 Base32 で配布）と、C（8バイトのカウンタ、初期値0で認証成功ごとに +1）です。

HOTP(K, C) の手順:
  1. C を 8 バイトのビッグエンディアン整数に変換する
  2. HS = HMAC-SHA1(K, C)            # 20 バイトの擬似ランダム列
  3. Sbits = DynamicTruncate(HS)     # 31 ビットの整数を抽出
  4. code  = Sbits mod 10^d          # d は桁数（既定 6）
  → 例: d=6 なら "287082" のように 0 埋めした 6 桁

要点は HMAC-SHA1(K, C) が擬似ランダム関数として働くことです。鍵 K を知らない攻撃者には、カウンタを1進めた出力が前の出力と無相関なランダム列にしか見えません（HMAC が PRF として振る舞う根拠は MAC と HMAC の設計原理 を参照）。だからカウンタという単純で予測可能な値を入れても、出てくるコードは予測不能になります。RFC 4226 は SHA-1 を基準としていますが、構成上 H は差し替え可能で、TOTP では SHA-256/SHA-512 も選べます。

dynamic truncation：毎回違う位置から抜き出す

桁数を減らす中核が **dynamic truncation（動的切り捨て）**です。20バイトの HMAC 出力から、その出力自身が指すオフセット位置の4バイトを抜き出します。

DynamicTruncate(HS[0..19]):
  offset = HS[19] AND 0x0f        # 末尾バイトの下位 4 ビット → 0〜15
  P = (HS[offset]   AND 0x7f) << 24   # 最上位ビットを落とす（符号対策）
    | (HS[offset+1] AND 0xff) << 16
    | (HS[offset+2] AND 0xff) << 8
    | (HS[offset+3] AND 0xff)
  return P                        # 31 ビットの非負整数

仕組みは二段です。まず末尾バイトの下位4ビットをオフセット（0〜15）とし、20バイトのどこから読むかを決めます。HMAC 出力は擬似ランダムなので、このオフセットも実質ランダムに散らばります。次にその位置から連続4バイト（32ビット）を読み、先頭バイトの最上位ビットを 0x7f でマスクして落とし、31ビットの非負整数 P を得ます。最上位ビットを落とすのは、言語によって最上位ビットが符号として解釈され、実装間で値がずれるのを防ぐための互換性対策です。

最後に P mod 10^d で桁数に丸めます。6桁なら 10^6 = 1000000 で割った余りなので 000000〜999999、8桁なら 10^8 です。31ビット（最大約21.4億）を100万で割るため、剰余の偏りは無視できる水準に収まります。

TOTP：カウンタを時刻に置き換える（RFC 6238）

**TOTP（Time-based OTP, RFC 6238）**は、HOTP を一切作り替えていません。カウンタ C の決め方だけを、イベント回数から「現在時刻を一定間隔で割った整数」へ差し替えた特殊化です。

T = floor((現在のUNIX時刻 - T0) / X)
TOTP(K) = HOTP(K, T)

  T0 = 起点時刻（既定 0、つまり 1970-01-01 00:00:00 UTC）
  X  = 時間ステップ秒（既定 30 秒）

たとえば UNIX 時刻が 1718000000 秒、X=30 なら T = floor(1718000000 / 30) = 57266666。この T をカウンタとして HOTP(K, T) を計算します。30秒の間は T が一定なので同じコードが出続け、次の30秒境界で T が +1 されコードが一斉に切り替わります。端末とサーバーは同じ K を持ち、各自が自分の時計から T を計算するだけなので、やはり通信は不要です。

時間ステップ X は安全性と使い勝手のトレードオフです。短くすると盗まれたコードの有効時間が縮みますが、入力が間に合わずユーザーが打ち損じます。長くすると入力は楽ですが攻撃者の利用窓が広がります。30秒は両者の妥協点として広く採用されています。

クロックドリフト：ずれた時計をどう許容するか

TOTP の弱点は、端末とサーバーの時計のずれ（クロックドリフト）です。端末の時計が数十秒ずれていると、双方が計算する T が食い違い、正しい秘密を持っているのに照合が通りません。RFC 6238 はこれを検証窓で吸収します。

サーバー側の検証（後方/前方に W ステップ許容）:
  自分の T を中心に T-W 〜 T+W を順に試す
  for delta in [-W .. +W]:
      if TOTP(K, T + delta) == 入力コード:
          認証成功（delta を記録しておくとよい）

W=1 なら T-1, T, T+1 の3ステップ、X=30 秒環境では実質前後90秒ぶんを許容します。窓を広げるほどドリフトに寛容になりますが、同時に有効なコードが増える＝攻撃者の当たり判定も広がるため、安全性が下がります。実務では W=1（前後1ステップ）が一般的な落としどころです。

HOTP のカウンタ同期：イベント版特有の問題

時刻同期の TOTP と違い、HOTP はカウンタ C のずれが起きます。端末側でコードを生成したのに送信・入力されず破棄されると、端末の C だけが進み、サーバーの C と食い違います。対策はサーバー側の**先読み窓（look-ahead window）**です。

サーバー C = 100 のとき、look-ahead s を許して照合:
  C, C+1, ..., C+s まで HOTP(K, ·) を試す
  一致した位置 C+k で認証成功 → サーバー C を C+k+1 に更新（リシンク）

ただし HOTP はコードが時間で失効しないのが構造的な弱点です。生成されたコードは次に使われるまで永続的に有効で、肩越しに見られたり書き留められたりすれば後から悪用されます。時間で自動失効する TOTP がモバイル認証アプリの主流になったのは、この使い勝手と安全性の両面が理由です。

総当たり耐性：強さはどこから来るか

OTP の総当たり耐性は、HMAC の暗号強度ではなく、コードの桁数とサーバー側のレート制限で決まります。ここを取り違えると設計を誤ります。

6桁コードは値域が 10^6 = 100万通りしかありません。攻撃者が1回の試行で当てる確率は 1/1000000。さらに TOTP では、検証窓 W のぶん有効コードが 2W+1 個に増えるので、W=1 なら成功確率は 3/1000000 に上がります。桁数だけでは防御として薄いため、必ずサーバー側で試行回数のレート制限とアカウントロックを併用します（レート制限の設計 も参照）。たとえば「1ステップあたり数回まで、超えたら一時ロック」とすれば、100万分の数という当たり確率では実用的な総当たりが成立しません。

まとめ

HOTP は「共有秘密 K とカウンタ C を HMAC に通し、dynamic truncation で31ビットに削り、10^d の剰余で d 桁にする」だけの仕組みです。HMAC が PRF として働くので、単純なカウンタから予測不能なコードが生まれます。TOTP はそのカウンタを (時刻 - T0) / X に置き換えただけの特殊化で、時間による自動失効を得る代わりにクロックドリフトの問題を抱え、前後ステップの検証窓で吸収します。総当たり耐性は HMAC の強度ではなく桁数とレート制限の積で決まり、共有秘密 K の管理がすべての前提です。これらは 多要素認証（MFA） の「所持」要素を支える実装であり、HMAC という土台を理解すれば内部動作はほぼ自明に追えます。