Metaの公開時刻サービスがNTSに対応、認証付きNTPをオープンソース化

発表内容

Metaは公開時刻サービスにおいて、nts.meta.comでNTS（Network Time Security、RFC 8915）をサポートすると発表した。NTSはパケットを認証する仕組みで、端末は受け取った時刻がMetaから送られたものであり、途中で改変されていないことを確認できる。従来のNTPは認証を持たないため、応答が本物かどうかを検証できなかった。

Metaはプロトコル、サーバ、クライアントをオープンソース化し、MetaのTimeライブラリとしてGitHubで公開した。特にAndroidやiOSでNTPクライアントを保守する開発者に対し、NTS対応を有効にするよう呼びかけている。同社は以前からntpdからchronyへの移行や精度改善（10ミリ秒から100マイクロ秒へ）を進めており、今回の取り組みは精度ではなく検証可能性を高めるものだと位置づけている。

なぜ認証が必要か

NTPは1985年以来、認証を持たないプロトコルだ。しかし証明書、トークン、署名の検証はすべて現在時刻を基準に行われる。TLS証明書のnotBeforeとnotAfterの比較、トークンの有効期限、リプレイ判定の時間窓、ログの相関と順序付けは、いずれも正しい時計を前提とする。ここには循環があり、X.509証明書の有効期間を検証するには現在時刻が必要だが、その時刻自体が認証されていない。

回避策は2つあるが、どちらも良くないとMetaは説明する。時計が設定されるまで検証をスキップする方法は、端末が最も危険な瞬間に無防備になる。発行者がnotBeforeを数分遡り、検証側が許容幅を広げる方法は、互いのずれを推測しているにすぎない。証明書の有効期間が398日あった頃は限定的な問題だったが、CA/Browser ForumのBallot SC-081v3により、公開TLS証明書の上限は2026年3月に200日、2027年3月に100日、2029年3月に47日へと段階的に短縮される。ドメイン検証の再利用期間も同時点で10日まで下がる。

時刻を狙う攻撃の影響は大きい。中間者攻撃は暗号を破る必要がなく、本物のサーバより先に応答するだけで成立する。時計を巻き戻せば失効した証明書が再び有効になり、進めればすべてが一度に失効する。NTPは32ビットの秒フィールドが2036年2月に一周するため、2037年と誤認した端末では補正計算が誤った時代に入り、時計を直す仕組みがかえって遠ざける。保持する証明書はすべて失効してTLSが失敗し、更新サービスにも到達できなくなる。復旧には工場出荷状態へのリセットや修理が必要になる。

NTSの仕組み

NTSは2段階で動作する。第1段階の鍵確立（NTS-KE）はTCP/4460上のTLS 1.3で行い、ALPNとしてntske/1を使う。クライアントとサーバはAEADアルゴリズムを合意し、RFC 5705のエクスポーターでTLSセッションから方向別のセッション鍵（C2SとS2C）を導出する。サーバは8個のクッキーを発行し、サーバネゴシエーションレコードで実際に使うNTPサーバを伝えて接続を閉じる。この処理はパケットごとではなく1度だけ行われる。

第2段階は認証付きNTPで、UDP/123上のNTPv4にNTS拡張フィールドを付けて行う。リクエストは一意な識別子、クッキー、認証子を運び、認証子はそれより前のすべてを対象にするが暗号化はしない。サーバはクッキーを開いてセッション鍵を取り出し、認証子を検証したうえで、識別子を返し、自身の認証子を付けて応答する。この認証子には新しいクッキーが暗号化されて格納される。

偽造パケットは検証に失敗して破棄される。MetaはNTS NAKを送らないため、失敗はパケットロスと区別できず、クライアントに再鍵交換を強制する攻撃には使えない。応答の再生は識別子が一致せず、対応するリクエストが見つからない。交換されるクッキーは応答の認証子の中に入るため、傍受者からは毎回異なる不透明なデータに見え、クライアントをネットワーク間で追跡できない。

ステートレスなクッキー設計

クッキーはサーバの状態をクライアントに預ける仕組みで、セッション鍵をAES-SIVで封印して格納する。素直な実装は全サーバに複製した鍵リングだが、それでは時刻サービスが分散状態の問題になってしまう。Metaは鍵を複製しない方法を選んだ。

各サーバは共有マスタシークレットと現在の日から封印鍵を導出する。ここでの日はUnixエポックからの24時間単位の整数で、タイムゾーンや夏時間の影響を受けず、同じ瞬間ならどのホストでも同じ値になる。この整数はクッキーの鍵IDとして平文で運ばれ、見たことのないクッキーを受け取ったサーバでも鍵を再導出して開ける。ローテーション境界のずれを吸収するため、2日前から1日先までを受け入れる。結果として鍵リング、複製、セッションテーブルが不要になり、鍵交換サーバとNTPサーバは互いに何も交換しない。プレーンなNTP経路は変更されておらず、拡張フィールドが無い場合は従来と同じコードが同じコストで動く。

使い方はchronyなら設定1行だと説明されている。nts.meta.comは鍵交換のみを終端し、サーバネゴシエーションレコードでtime.meta.comを案内するため、設定したホストと実際に通信するホストは異なる。単一のserver行では単一障害点になるため、Metaはpoolの使用を勧める。maxsources個の独立した関連がそれぞれ独自のTLSセッションと鍵を持ち、5つのソースが約20分で立ち上がるという。

防げない攻撃と限界

NTSは遅延攻撃を防がない。RFC 8915にも明記されており、パケットを保持する攻撃者は導入した遅延の半分まで時計をずらせる。すべてのバイトが本物であるため、暗号技術では検出できない。認証が示すのは誰が書いたかであり、どれだけ飛んでいたかではない。対策は複数の独立したソース、健全性チェック、段階制限といった従来の方法になる。

起動時のブートストラップも未解決だ。NTS-KEはTLS上で動き、TLSは正しい時計を要求するため、先ほどの循環が再び現れる。RTCが死んでいる端末でも、最初のハンドシェイク前に概ね正しい時刻を得る必要がある。またNTSは経路を認証するのであって答えを認証するのではなく、正しく設定・認証されたサーバが単に間違っていれば、正しい署名付きの誤った時刻が返る。クォーラムや健全性チェック、監視は依然として必要だとしている。

単調性の問題もある。認証された時刻も壁時計であり、うるう秒や補正で巻き戻ることがある。Cloudflareの権威DNSは2016年末にこれを踏み、うるう秒をまたいで測ったリゾルバの往復時間が負になり、上流の選択に伝播してGoのrand.Int63n()がパニックした。何も偽造されておらず誤配信もなかったが、経過時間を測るコードでは単調時計を使うべきだとMetaは指摘する。