システム・運用#98

コマンド認証とセキュリティ — 「正しく届く」と「正規の相手から届く」は別問題

COP-1は再送によってコマンドが確実に正しい順序で届くことを保証したが、それが正規の管制センターから送られたものかは何も保証しない。MAC(メッセージ認証コード)とリプレイ対策の数式で、探査機コマンドリンクの認証設計の基礎を理解する。

前提知識: COP-1 — コマンドを確実に、正しい順序で届ける再送制御プロトコル

コマンド認証MACHMACリプレイ攻撃CCSDS SDLS

この回で学ぶこと

前回、COP-1というプロトコルが、地上局から探査機へのコマンドが1個も欠落せず、送信した順序どおりに届くことをどう保証しているかを見ました。FARM/FOPという2つの状態機械が、シーケンス番号 $N(S)$ とCLCWのやり取りだけで、フレームの完全性と順序を保証する仕組みでした。

ここで、あえて意地の悪い問いを立ててみましょう。COP-1が保証しているのは本当に「コマンドが正しく届く」ことの全てでしょうか。FARMの受理判定をもう一度思い出してください。

\text{action}(N(S)) = \begin{cases} \textbf{受理}, \ V(R) \leftarrow V(R)+1 \!\!\pmod{256} & \text{if } N(S) = V(R) \\[4pt] \textbf{棄却} & \text{otherwise} \end{cases}

この判定式が見ているのはただ1つ、フレームに書かれたシーケンス番号が期待値と一致するかどうかだけです。FARMは、そのフレームが本当に正規の地上局から送られてきたものかどうかを、原理的に一切気にしていません。もし何者か(悪意ある第三者、あるいは地上系の設定ミスや機器故障)が、正しい $N(S)$ さえ書いてあれば、FARMはそのフレームを喜んで受理し、期待値をインクリメントし、探査機はその中身のコマンドを実行してしまいます。

これは決して机上の空論ではありません。COP-1が保証する「完全性」と「順序」は、いわば信頼性(reliability)の問題です。フレームが失われないか、順番が入れ替わらないか。これに対して、ここから扱うのはセキュリティ(security)の問題です。届いたフレームが、名乗っている送信元から本当に送られたものかどうか。この2つは似ているようでまったく別の性質であり、片方を満たしても他方は自動的には満たされません。ちょうど、書留郵便が「確実に、順番通りに」届くことを保証しても、差出人欄に書かれた名前が本物かどうかまでは保証しないのと同じです。この回では、この「正規の送信元から来たことをどう保証するか」というコマンド認証の基礎を、MAC(メッセージ認証コード)という道具を使って数式で追っていきます。

直感的導入: 封筒の宛名と中身の違い

COP-1のシーケンス番号を、書留郵便の通し番号にたとえたことを思い出してください。通し番号は「何通目の手紙か」「抜けなく順番に届いたか」を管理する仕組みであり、封筒の外側に書かれた事務的な情報です。しかし通し番号だけでは、その手紙の差出人が本当に名乗っている本人かどうかは何もわかりません。誰かが正しい通し番号を偽造して手紙を紛れ込ませれば、郵便配達員(FARM)は何の疑いもなくそれを配達してしまいます。

探査機のコマンドリンクにおいても事情は同じです。攻撃者(あるいは誤動作した地上系)が、正しいシーケンス番号を持つTCフレームを何らかの方法で探査機のアップリンクに注入できたとすれば、そのフレームの中身がどんなコマンドであっても、FARMの受理ロジックはそれを拒む理由を持ちません。COP-1より下位のCLTU(Command Link Transmission Unit)の誤り検出符号も、ビット誤りを検出するためのものであって、送信元を証明するためのものではありません。つまり、これまで学んできたレイヤーのどこにも、「送信元の正当性を確認する」という機能は存在しなかったのです。

ではどうすれば、受信側が「このメッセージは、鍵を知っている正規の相手が作ったものに違いない」と数学的に確信できるのでしょうか。この問いに答えるのがメッセージ認証コード(MAC)です。

メッセージ認証コード(MAC)の数式的な仕組み

MACの基本アイデアは、送信側と受信側だけが知っている秘密鍵と、送りたいメッセージを、暗号学的ハッシュ関数に通して短い「タグ」を作り、それをメッセージに付けて送る、というものです。

送信側(地上局)と受信側(探査機)が、あらかじめ安全な方法で共有している秘密鍵を $K$ とします。送りたいメッセージ(この文脈ではTCフレームの本体、コマンドの中身)を $M$ とすると、MAC関数 $\mathrm{MAC}_K(\cdot)$ を使ってタグ $T$ を計算します。

T = \mathrm{MAC}_K(M)

送信側は $(M, T)$ の組をそのまま送ります。 $M$ 自体は暗号化されていないことに注意してください(この点は次の節で詳しく扱います)。受信側は、届いた $M'$ と $T'$ に対して、自分が持っている同じ鍵 $K$ を使ってタグを計算し直し、

T_{\text{expected}} = \mathrm{MAC}_K(M')

これが届いたタグと一致するかどうかを検証します。

\text{verify}(M', T') = \begin{cases} \textbf{受理} & \text{if } T' = \mathrm{MAC}_K(M') \\ \textbf{拒否} & \text{otherwise} \end{cases}

この仕組みが機能するために、MAC関数には次の2つの性質が要求されます。

鍵を知らなければ、正しいタグを(現実的な計算量で)偽造できない。 $K$ を知らない攻撃者が、ある $M$ に対して正しい $T = \mathrm{MAC}_K(M)$ を計算することは、総当たり以外に事実上不可能でなければなりません。
メッセージが1ビットでも変われば、タグはほぼ確実に変わる。 これにより、途中でメッセージが改ざんされれば検証は必ず失敗します。

実際に広く使われているMACの構成法が HMAC (Hash-based MAC) です。HMACは既存の暗号学的ハッシュ関数 $H$ (SHA-256など)を組み合わせて、次のような形でMACを構成します(詳細な内部構造は暗号理論の教科書に譲りますが、骨格は次の通りです)。

\mathrm{HMAC}_K(M) = H\big((K \oplus \text{opad}) \,\|\, H((K \oplus \text{ipad}) \,\|\, M)\big)

ここで $\text{opad}, \text{ipad}$ は固定の定数パディング、 $\|$ は連結、 $\oplus$ はXORです。この二重ハッシュ構造は、単純に $H(K \| M)$ とするだけでは生じてしまう特定の攻撃(ハッシュ関数の内部構造に起因する拡張攻撃など)を防ぐために設計されています。重要なのは内部の詳細よりも、「鍵と可変長のメッセージから、固定長の短いタグを、鍵を知らない者には偽造不可能な形で生成する」という機能そのものです。

宇宙機のコマンドリンクでは、HMACに加えて、あるいはその代替として、AESなどのブロック暗号をベースにした CMAC (Cipher-based MAC) も使われます。どちらを使うにせよ、探査機は各TCフレームの本体 $M$ と、地上局が計算して付加したタグ $T$ を受け取り、自分も保持している秘密鍵 $K$ で $T$ を検算する、という構造は共通です。検算が一致しなければ、そのフレームはFARMのシーケンス番号チェックを通っていたとしても、認証の段階で棄却されます。

なぜ「秘匿性」より「認証性」が優先されるのか

ここで、暗号を扱う多くの人が最初に抱く疑問に答えておく必要があります。「メッセージ $M$ 自体を暗号化して秘匿しなくていいのか」という疑問です。

地上のインターネット通信(たとえばTLS)では、暗号化(秘匿性)と認証(改ざん検知・送信元確認)はセットで扱われるのが普通です。しかし探査機のコマンドリンクの設計では、しばしば秘匿性より認証性が優先される、あるいは認証だけを実装して暗号化は行わない(平文でコマンドを送る)という判断がなされます。これは実装コストの都合だけでなく、明確なリスク非対称性に基づく設計判断です。

コマンドの中身が傍受されるリスクを考えてみましょう。攻撃者がアップリンクを盗聴して「いつ、どんな種類のコマンドが送られたか」を知ったとしても、それだけでは実害は限定的です。コマンドの中身を知ることと、探査機にそのコマンドを実行させることの間には大きな隔たりがあります。傍受されたコマンドの知識は、せいぜい運用パターンの推測に使われる程度で、探査機の状態を直接変化させることはありません。

これに対して、偽コマンドが受理・実行されるリスクは桁違いに深刻です。認証機構がなければ、シーケンス番号さえ合わせられれば、姿勢制御スラスタの誤噴射、安全モードへの不正な強制移行、あるいはより悪意的なシナリオでは軟件の不正な書き換えといった、探査機の運用継続そのものを脅かすコマンドが実行されてしまう可能性があります。数十億円から数千億円規模の資産であり、一度失われれば(月惑星間の距離を考えれば)物理的な修理が事実上不可能な探査機にとって、これは致命的です。

つまり設計判断の非対称性を整理すると、次のようになります。

リスク	秘匿性がない場合の実害	認証性がない場合の実害
内容	コマンドの種類・タイミングが第三者に知られる	偽造・改ざんされたコマンドが実行される
深刻度	限定的(情報漏洩レベル)	致命的(機体喪失・機能喪失の可能性)

この非対称性ゆえに、限られた搭載計算資源とリンク帯域を投じるなら、まず認証を優先する、という設計思想が広く採用されています。もちろんミッションによっては秘匿性も重要になる場合(軍事・国家安全保障関連ペイロードなど)がありますが、一般的な科学探査ミッションのコマンドリンクにおいては「見られても実害は小さいが、なりすまされたら終わり」という優先順位づけが合理的なのです。

リプレイ攻撃とその対策: なぜタグだけでは不十分か

MACによる認証だけでは、実はまだ穴が残っています。それが**リプレイ攻撃(replay attack)**です。

考えてみましょう。攻撃者は鍵 $K$ を知らないので、任意の新しいメッセージに対して正しいタグを偽造することはできません。しかし攻撃者は、過去に地上局が実際に送信した正規のフレーム $(M, T)$ の組を盗聴によって丸ごと記録しておき、それを後になってもう一度アップリンクに送り込むことができます。 $M$ も $T$ も本物なので、探査機側の検証は

T \stackrel{?}{=} \mathrm{MAC}_K(M)

を正しく成立させてしまい、認証は通ってしまいます。もし $M$ が「安全モードを解除せよ」や「特定のスラスタを噴射せよ」といった、実行タイミングによっては危険なコマンドだった場合、それを意図しないタイミングで再実行させられてしまう危険があります。

ここで前回学んだCOP-1のシーケンス番号 $N(S)$ が再び関係してきます。COP-1はもともと信頼性(完全性・順序)のための仕組みでしたが、その副産物として「単調に増加する番号」という構造を持っています。この構造をMACの計算対象に含めることで、リプレイ対策に転用できます。具体的には、タグを $M$ 単体からではなく、 $M$ とシーケンス番号(あるいは認証専用のカウンタ) $N$ を連結したものから計算します。

T = \mathrm{MAC}_K(N \,\|\, M)

受信側(探査機)は、認証に使われる番号 $N$ についても「これまでに受理した最大の番号より大きいこと」を検証条件に加えます。

\text{verify}(N', M', T') = \begin{cases} \textbf{受理}, \ N_{\max} \leftarrow N' & \text{if } T' = \mathrm{MAC}_K(N' \| M') \ \text{かつ} \ N' > N_{\max} \\ \textbf{拒否} & \text{otherwise} \end{cases}

こうしておけば、攻撃者が過去の $(N, M, T)$ の組をそのまま再送しても、 $N' > N_{\max}$ の条件を満たさない(すでに使われた番号である)ため拒否されます。COP-1のシーケンス番号をそのまま流用する設計もあれば、認証層で独立したカウンタを持たせる設計もありますが、いずれにせよ「単調増加する値をMACの計算に含め、後退を許さない」という考え方は共通です。

もう1つの対策がタイムスタンプの利用です。メッセージに送信時刻 $t_{\text{send}}$ を含めてタグを計算し、

T = \mathrm{MAC}_K(t_{\text{send}} \,\|\, N \,\|\, M)

受信側は自分の現在時刻 $t_{\text{recv}}$ との差が、許容できる時間窓 $\Delta t_{\text{allow}}$ の範囲内にあることも検証条件に加えます。

|t_{\text{recv}} - t_{\text{send}}| \le \Delta t_{\text{allow}}

この時間窓 $\Delta t_{\text{allow}}$ の設計には、前回のCOP-1のタイムアウト $T_1$ の議論と同じ悩みが再登場します。地球からの片道光行時間が数分から数時間に及ぶ深宇宙ミッションでは、 $\Delta t_{\text{allow}}$ を短く絞りすぎると正規のコマンドまで時刻窓の外に出て拒否されてしまい、逆に長く取りすぎるとリプレイ攻撃への耐性が弱まります。シーケンス番号ベースの対策(単調増加性のみを見る)は光行時間に依存しないという利点があるため、実際にはシーケンス番号による後退防止を主軸に、タイムスタンプは補助的に(あるいは時刻同期の精度が確保できる範囲で)組み合わせる、という設計が現実的な落としどころになります。

実務での使われ方

コマンド認証は、もはや「あれば望ましい追加機能」ではなく、多くのミッションにとって必須のセキュリティ要件になっています。背景には、衛星・探査機がますます地上のネットワークインフラと接続され、商用地上局ネットワークや複数国の地上局を横断運用する クロスサポート(国際協力運用)が一般化し、攻撃対象領域(アタックサーフェス)が拡大してきたという事情があります。実際、地上の商用通信衛星に対する不正コマンド注入や妨害の事例が過去に報告されており、政府機関(米国のNIST、CISAなど)からも宇宙システムのサイバーセキュリティに関するガイドラインが出されるようになりました。

CCSDSは、この認証・秘匿機能を標準化するために SDLS (Space Data Link Security Protocol)、CCSDS 355.0-B Space Data Link Security Protocol を規定しています。SDLSは今回扱ったMACによる認証(Authentication)と、必要に応じた暗号化(Encryption)の両方をサポートする枠組みで、TCフレームやTM(テレメトリ)フレームのデータユニットにセキュリティヘッダ・トレーラを付加する形で、COP-1やTC/TM宇宙データリンクプロトコルといった下位レイヤーの上に(あるいはそれと組み合わさる形で)動作します。SDLSは認証アルゴリズムそのもの(AES-CMACなど)を規定するのではなく、鍵管理・アンチリプレイカウンタ・セキュリティヘッダのフォーマットといった「認証を安全に運用するための枠組み」を提供する点が特徴です。次回はこのSDLSの構造を詳しく見ていきます。

NASAのミッションでは、深宇宙探査機に対するコマンド認証は多くの現行ミッションで実装されており、地球周回衛星の分野でも、米空軍(現・米宇宙軍)がAFSCN(Air Force Satellite Control Network)経由で運用する衛星群において、コマンド認証の実装がミッション要求として明記されるようになっています。商用の静止通信衛星についても、乗っ取り(ハイジャック)による軌道上資産の不正操作を防ぐため、コマンド認証は業界標準的な要件になりつつあります。

演習問題

FARMのシーケンス番号チェックだけではコマンドの送信元を保証できない理由を、この回で述べた「信頼性」と「セキュリティ」の違いという観点から自分の言葉で説明してください。
ある地上局が、鍵 $K$ を使ってメッセージ $M_1 =$ 「太陽電池パドルを展開せよ」に対してタグ $T_1 = \mathrm{MAC}_K(M_1)$ を計算し送信したとします。攻撃者が $(M_1, T_1)$ を盗聴・記録し、1週間後に同じ組をそのまま再送した場合、(a) シーケンス番号を含めないMAC $T = \mathrm{MAC}_K(M)$ と、(b) シーケンス番号を含めたMAC $T = \mathrm{MAC}_K(N\|M)$ のそれぞれで、探査機側の検証結果がどう変わるか説明してください。
「コマンドは暗号化せず認証だけを行う」という設計判断について、この回で述べたリスクの非対称性(傍受された場合の実害 vs. 偽造が受理された場合の実害)を踏まえて、あなたが探査機の運用責任者だったらどのような追加条件(ミッションの種類、ペイロードの機微性など)のもとで暗号化も併用すべきだと考えるか、理由とともに論じてください。
地球-土星間のように片道光行時間が1時間を超えるミッションで、認証にタイムスタンプベースの時間窓 $|t_{\text{recv}} - t_{\text{send}}| \le \Delta t_{\text{allow}}$ を主軸に採用した場合、どのような運用上の問題が起こりうるか、COP-1のタイムアウト $T_1$ 設計で議論したRTLTの問題と関連づけて説明してください。またシーケンス番号ベースの後退防止策がなぜこの問題を回避できるかも述べてください。

まとめと次回予告

COP-1が保証する「完全性」と「順序保証」は、探査機コマンドリンクの信頼性を担保するものであって、そのコマンドが正規の送信元から来たものであることを保証するセキュリティの問題とは独立でした。この回では、共有鍵とハッシュ関数を使ってメッセージの改ざん検知と送信元認証を同時に行うMAC(HMAC/CMAC)の基本原理を数式で確認し、探査機のコマンドリンクでは「秘匿性より認証性が優先される」という設計判断が、傍受のリスクと偽造受理のリスクの非対称性から合理的に導かれることを見ました。さらに、正規のメッセージをそのまま再送するリプレイ攻撃への対策として、シーケンス番号やタイムスタンプをMACの計算対象に含め、単調増加性や時間窓を検証条件に加える仕組みを見ました。

次回は、これらの認証機構を実際の宇宙データリンクにどう組み込むかを標準化した CCSDS SDLS (Space Data Link Security Protocol) を詳しく扱います。セキュリティヘッダのフォーマット、鍵管理の考え方、そしてCOP-1やTC宇宙データリンクプロトコルとどう積み重なって動作するのかを見ていきます。

参考文献

CCSDS 355.0-B, Space Data Link Security Protocol, Blue Book
CCSDS 232.1-B, Communications Operation Procedure-1, Blue Book
CCSDS 350.9-G, Space Data Link Security Protocol — Extended Procedures, Green Book(実装ガイダンス)
M. Bellare, R. Canetti, H. Krawczyk, Keying Hash Functions for Message Authentication, CRYPTO ‘96(HMACの原論文)
NIST FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC)
NIST SP 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
CISA/NIST, Foundational Practices for Space Systems Cybersecurity (宇宙システムのサイバーセキュリティガイドライン)