CCSDS SDLS — MACとフレーム構造を統合する宇宙データリンクセキュリティ標準

この回で学ぶこと

コマンド認証の回で、MAC(メッセージ認証コード)という道具そのものの数学的な仕組みを学びました。共有鍵 $K$ とメッセージ $M$ からタグ $T = \mathrm{MAC}_K(M)$ を計算し、受信側が検算することで送信元の正当性を確認する——この原理自体は、どんな通信路にも適用できる汎用的な暗号理論です。

しかし理論と実装のあいだには、まだ大きな溝があります。タグ $T$ は何バイトで、TCフレームやTMフレームのどこに書き込まれるのか。鍵 $K$ はどの鍵を使ったものかを、受信側はどうやって知るのか。暗号化(秘匿性)まで行う場合、初期化ベクトルはどこに置くのか。認証つきの暗号化と、認証だけの場合とで、フレームの見た目はどう変わるのか。これらは数学の問題ではなく、フォーマットの問題です。そしてフォーマットが標準化されていなければ、地上局と探査機の実装がそれぞれ独自にタグの置き場所を決めてしまい、相互運用性が崩壊します。

この溝を埋めるのが、TM宇宙データリンクプロトコルの回で学んだトランスファーフレームの構造に、MACのタグや暗号化パラメータを具体的にどう埋め込むかを規定した標準、CCSDS 355.0-B Space Data Link Security Protocol (SDLS) です。この回では、SDLSがトランスファーフレームに追加する「セキュリティヘッダ」「セキュリティトレーラ」という2つの新しいフィールドの構造、SDLSが提供する3種類のセキュリティサービスの使い分け、そして鍵管理の基本的な考え方を扱います。MACの原理そのものやフレームの基本構造は再導出せず、その2つをどう統合するかにこの回の焦点を絞ります。

直感的導入: 封筒に「封蝋」と「差出人証明シール」を追加する

コマンド認証の回では、COP-1のシーケンス番号を書留郵便の通し番号にたとえました。この比喩をもう一段進めましょう。

通し番号だけでは差出人の正当性を証明できないので、封筒に「封蝋(ふうろう)」——つまり差出人だけが持つ印章で押した蝋の塊——を追加するとします。受取人は封を開ける前に、蝋に刻まれた紋章が本物の印章と一致するかを確認できます。もし内容物そのものも他人に見られたくないなら、さらに手紙を暗号文に変換してから封筒に入れる、という工程も追加できます。

ここで重要なのは、封蝋や暗号化は「封筒」という既存のフォーマットに後から追加された仕組みであり、封筒そのものの基本構造(宛名・通し番号の書き方)は変わらないという点です。SDLSがやっていることもまったく同じです。TM宇宙データリンクプロトコルの回で見たプライマリヘッダ・データフィールド・OCF・FECFという既存のフレーム構造はそのまま残し、そのデータフィールドの前後に、封蝋にあたる「セキュリティヘッダ」と「セキュリティトレーラ」を追加で挿入する——これがSDLSのフレーム設計の骨格です。

さらに、封蝋の紋章にも「誰の印章か」を示す情報(鍵ID)が刻まれており、また同じ印章を使い続けると偽造される危険が高まるため、印章そのものを定期的に新調する(鍵の世代管理)必要があります。この回では、この封蝋の具体的な作り方——フィールド構造、3種類のサービスの選び方、印章(鍵)の更新方法——を数式とフォーマット表で追っていきます。

SDLSが追加する2つのフィールド: セキュリティヘッダとセキュリティトレーラ

TM宇宙データリンクプロトコルの回で見た通り、標準的なTMトランスファーフレームは次の構造でした。

$$\text{Primary Header} \;\; \text{Secondary Header(任意)} \;\; \text{Transfer Frame Data Field} \;\; \text{OCF(任意)} \;\; \text{FECF(任意)}$$

SDLSは、この Transfer Frame Data Field の内部に、セキュアにしたいペイロード(実際のSpacePacket群やコマンドデータ)を包む形で、前後に新しいフィールドを挿入します。

$$\underbrace{\text{Primary/Secondary Header}}_{\text{既存}} \;\; \underbrace{\text{Security Header}}_{\text{新規}} \;\; \underbrace{\text{Payload Data Unit}}_{\text{保護対象データ}} \;\; \underbrace{\text{Security Trailer}}_{\text{新規}} \;\; \underbrace{\text{OCF / FECF}}_{\text{既存}}$$

つまりSDLSは、既存のTM/TCフレームフォーマットに割り込むのではなく、データフィールドという「箱」の中身のさらに内側に、もう一段の入れ子構造を作るという設計です。これにより、フレーム同期・VC逆多重化といった下位層の処理(TM宇宙データリンクプロトコルの回参照)はSDLSの有無にかかわらずまったく変更なしで動作します。地上局の受信機はまずいつも通りフレームを切り出し、プライマリヘッダのSecurity Header Flagなどの指示に従って初めて、データフィールドの中身をSDLSとして解釈するかどうかを判断します。

Security Header の内訳

Security Headerは、次の3つの主要サブフィールドから構成されます。

サブフィールド	典型的なビット幅	役割
Spacecraft ID (SPI, Security Parameter Index) または鍵ID	16 (実装依存)	どの鍵・どのセキュリティ関連付け(パラメータの組)を使ってこのフレームが保護されたかを示す
Initialization Vector (IV)	実装依存(例: 64〜128)	暗号アルゴリズムが必要とする初期化ベクトル。同じ鍵で暗号化する場合でも、フレームごとに異なる値を使うことでパターンの繰り返しを防ぐ
Sequence Number (アンチリプレイカウンタ)	実装依存	コマンド認証の回で見た $N' > N_{\max}$ の検証に使う、単調増加するカウンタ

ここでSPI (Security Parameter Index) という考え方が重要です。SPIは「使用している鍵そのもの」ではなく、「鍵・アルゴリズム・鍵の世代・その他のセキュリティパラメータの組」を指し示すインデックスです。受信側(探査機、あるいは地上局)は、あらかじめSPIごとに対応するパラメータの組を内部テーブルとして保持しており、受け取ったフレームのSPI値を見て「このフレームはAES-256-CMACで、第3世代の鍵$K_3$を使って保護されている」といったパラメータを引き当てます。

$$\text{SPI} \;\longrightarrow\; (\text{鍵ID}, \ \text{暗号アルゴリズム}, \ \text{鍵の世代}, \ \cdots)$$

この間接参照(インデックスを経由する設計)により、実際のフレームのビット列には鍵の中身そのものは一切現れません。鍵の更新や、アルゴリズムの切り替えは、送受信双方のSPIテーブルを同期させるだけで実現でき、フレームフォーマット自体は変更する必要がありません。

Security Trailer の内訳

Security Trailerは、多くの場合1つの主要フィールドだけを持ちます。

サブフィールド	典型的なビット幅	役割
MAC (Message Authentication Code) / ICV (Integrity Check Value)	32〜256(アルゴリズム依存)	コマンド認証の回で見たMACのタグ $T$ そのもの

つまりSecurity Trailerが運んでいるのは、コマンド認証の回で

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

として定式化した、まさにあのタグ $T$ です。SDLSの貢献は、この $T$ をフレームのどの位置に、何ビットで格納するかを標準化した点にあります。また、認証の対象となるメッセージ $M$ が「このフレームのSecurity Headerを含むデータフィールド全体」であることを明確に規定しているため、地上局と探査機のどちらの実装でも、検算に使うビット列の範囲について解釈のズレが生じません。

SDLSがサポートする3つのセキュリティサービス

SDLSは、ミッションの要求に応じて次の3つのサービスから選択できるように設計されています。コマンド認証の回で議論した「秘匿性より認証性が優先されることが多い」という設計判断が、ここで実際の選択肢として具体化されます。

1. Authentication (認証のみ)

Payload Data Unit は平文のまま送り、Security Trailer にMACタグ $T = \mathrm{MAC}_K(M)$ だけを付加します。データの中身は誰でも読めますが、改ざん・なりすましは検出できます。

$$\text{Frame} = \text{Header} \,\|\, \text{Security Header} \,\|\, \underbrace{M}_{\text{平文}} \,\|\, \underbrace{T = \mathrm{MAC}_K(M)}_{\text{Security Trailer}}$$

これはコマンド認証の回で扱った「秘匿性より認証性を優先する」設計判断をそのまま実装したモードで、多くの科学探査ミッションのTCフレーム(コマンド)保護に使われる標準的な選択です。

2. Encryption (暗号化のみ)

逆に、Payload Data Unit を暗号化して秘匿しつつ、改ざん検知のためのMACは付けないモードです。

$$\text{Frame} = \text{Header} \,\|\, \text{Security Header(IV含む)} \,\|\, \underbrace{E_K(M)}_{\text{暗号文}}$$

ここで $E_K(\cdot)$ は共通鍵暗号(AESなど)による暗号化関数です。このモードは、内容の秘匿は必要だが改ざん検知の優先度が相対的に低いという特殊な要求がある場合にのみ選ばれ、実運用では次の第3のモードに比べて採用例は限られます。理由は単純で、暗号化されたデータであっても、攻撃者が暗号文のビットをランダムに書き換えて送り込めば、探査機側の暗号アルゴリズムはそれを「壊れた平文」として復号してしまい、改ざんの有無を判別する手段がないためです。

3. Authenticated Encryption (認証付き暗号化)

秘匿性と認証性の両方が必要な場合に使われる、最も堅牢なモードです。暗号化とMAC計算を組み合わせ、多くの実装では AES-GCM (Galois/Counter Mode) のような、暗号化と認証タグ生成を一体化したアルゴリズムを使います。

$$\text{Frame} = \text{Header} \,\|\, \text{Security Header(IV含む)} \,\|\, \underbrace{E_K(M)}_{\text{暗号文}} \,\|\, \underbrace{T = \mathrm{MAC}_K(\text{IV} \,\|\, E_K(M))}_{\text{Security Trailer}}$$

AES-GCMのようなAEAD (Authenticated Encryption with Associated Data) アルゴリズムでは、暗号化とタグ生成が単一のパス(1回の暗号処理)で同時に行われるよう設計されており、認証だけのモードと暗号化だけのモードを別々に実行するより計算コストが低く抑えられるという実装上の利点もあります。これは、後述する搭載計算資源の制約が厳しい宇宙機にとって、無視できない設計上の魅力です。

3つのサービスの選択は、ミッションのペイロードの機微性や、探査機側の計算資源・帯域の余裕によって決まります。次の表に整理します。

サービス	秘匿性	改ざん検知	典型的な用途
Authentication	なし	あり	一般的な科学探査ミッションのTCフレーム(コマンド)保護
Encryption	あり	なし	内容秘匿が主目的で、実運用での採用例は限定的
Authenticated Encryption	あり	あり	国家安全保障関連ペイロード、商用衛星の重要機能、秘匿性も要求される高価値ミッション

鍵管理の基本的な考え方

MACや暗号化アルゴリズムがどれほど数学的に堅牢であっても、鍵 $K$ そのものの管理がずさんであれば全体のセキュリティは崩壊します。SDLSは鍵管理の詳細な実装(具体的な鍵配送プロトコルの中身)までは規定しませんが、フレームフォーマットとして鍵管理を支える2つの仕組みを組み込んでいます。

鍵の事前共有と鍵ID(SPI)による世代管理

宇宙機との通信では、地上のインターネットのように公開鍵基盤(PKI)やTLSハンドシェイクのようなオンラインでの鍵合意を毎回行うことは、通信の往復時間(RTLT)や搭載計算資源の制約から現実的ではありません。そのため、鍵 $K$ は打ち上げ前に探査機に搭載されるか、運用中に別の(すでに認証された)チャンネルを通じて安全にアップロードされる**事前共有鍵(pre-shared key)**方式が主流です。

問題は、1つの鍵を運用期間中ずっと使い続けると、次のようなリスクが蓄積することです。

• 同じ鍵で暗号化されたデータ量が増えるほど、暗号解析による鍵の推定リスクが理論的に高まる。
• 鍵が万が一漏洩した場合、運用期間全体のセキュリティが一度に無効化される。
• ミッションの途中で新しい地上局や運用チームが加わる際、古い鍵をそのまま渡し続けるのは望ましくない。

この問題への対策が、Security Headerで見た SPI(鍵ID)による複数世代の鍵管理です。地上局と探査機は、単一の鍵ではなく「鍵ID 1: 初期鍵」「鍵ID 2: 第1回更新後の鍵」「鍵ID 3: 第2回更新後の鍵」…というように、番号付きの鍵の系列を保持します。

$$\text{SPI} = i \;\longrightarrow\; K_i \qquad (i = 1, 2, 3, \ldots)$$

鍵を更新する際は、新しい鍵 $K_{i+1}$ を(旧鍵 $K_i$ による認証付き暗号化などで保護した上で)アップロードし、以後のフレームでは Security Header の鍵IDフィールドを $i+1$ に切り替えるだけで、フレームフォーマット自体は変更せずに鍵のロールオーバー(切り替え)が行えます。受信側は複数世代の鍵をしばらく並行して保持しておき、切り替えの過渡期に生じうる新旧鍵混在のフレームにも対応できるようにするのが一般的な運用です。

アンチリプレイカウンタとの関係

Security Headerに含まれるSequence Number(アンチリプレイカウンタ)は、コマンド認証の回で導入した「単調増加する番号をMACの計算対象に含め、後退を許さない」という考え方を、SDLSのフィールドとして正式に位置づけたものです。

$$\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}$$

鍵の世代(SPI)が切り替わった際には、このアンチリプレイカウンタも同時にリセットまたは引き継ぎの規則を明確に決めておく必要があります。カウンタの扱いが曖昧なまま鍵だけを切り替えると、旧世代の鍵で作られた正規のフレームが、新世代のカウンタ検証で誤って拒否されたり、逆にリプレイ耐性の穴が生まれたりする可能性があるため、SDLSの実装ガイダンス(後述するGreen Book)ではこの遷移手順が詳しく扱われています。

実務での使われ方

SDLSは2015年に最初の版がCCSDSの標準として発行されて以降、段階的に採用が進んでいますが、その普及状況は決して一様ではありません。

実装状況の現状。 コマンド認証の回で触れたように、MACによるコマンド認証そのものは多くの現行ミッションで実装が進んでいますが、SDLSが規定するフルセットの機能(暗号化を含む3サービスすべて、鍵管理の自動化、TMダウンリンクまで含めた全面適用)を採用しているミッションはまだ限定的です。特に**暗号化(秘匿性)**の実装は、認証に比べて採用が遅れる傾向があります。これはコマンド認証の回で見たリスクの非対称性——「傍受されても実害は限定的、なりすまされたら致命的」——がそのまま反映された結果と見ることができます。

なぜセキュリティ機能の後付けが難しいのか。 多くの現行ミッションは、SDLSが標準化される以前に設計・打ち上げられた探査機・地上系を今も運用し続けています。これらにセキュリティ機能を後付けするのは、地上のソフトウェアシステムにパッチを当てるのとはわけが違う困難を伴います。

• 帯域の制約: Security HeaderとSecurity Trailerを追加すれば、その分だけフレームあたりのオーバーヘッドが増え、実データに使える帯域が減ります。リンクバジェットがぎりぎりに設計された深宇宙リンクでは、この数十ビットの追加ですら無視できないコストになり得ます。
• 搭載処理能力の制約: MAC計算・暗号化・復号は、探査機の限られた搭載計算機資源(多くは地上の一般的なCPUに比べて桁違いに非力な、放射線耐性を優先した実装)の上でリアルタイムに実行する必要があります。特に暗号化アルゴリズムは計算コストがMAC単体より高く、電力予算の厳しい小型探査機やCubeSatでは実装自体が難しい場合があります。
• 既存プロトコルとの互換性: 打ち上げ済みの探査機のフライトソフトウェアは、原則として軌道上で全面的な書き換えができません。SDLS対応は多くの場合、次世代の探査機の設計段階から組み込む形で進められており、既存の運用中ミッションへの遡及適用は限定的にならざるを得ません。
• 鍵管理の運用コスト: 鍵の事前共有・世代管理・ロールオーバーの手順は、地上の運用チーム側にも新しい業務プロセスと訓練を要求します。国際協力運用(クロスサポートの回参照)では、複数国・複数機関がSPIテーブルや鍵配送の手順を整合させる必要があり、技術的な難しさに加えて組織間調整のコストも発生します。

これらの制約から、SDLSの採用は「新規ミッションの設計段階からセキュリティ要件を組み込む」形で徐々に広がっているのが現状であり、既存の宇宙インフラ全体に一律に適用されるまでには時間がかかると見られています。NASA・ESAともに、新規開発ミッションの調達要求にSDLS準拠(あるいは同等のセキュリティ機能)を含めるケースが増えており、CCSDSも実装ガイダンスとして CCSDS 350.9-G (SDLS Extended Procedures, Green Book) を発行し、鍵管理手順の具体例を補足しています。

演習問題

1. SDLSのSecurity Headerに含まれる「Security Parameter Index (SPI)」が、鍵そのものではなく「鍵・アルゴリズム・鍵の世代の組を指すインデックス」として設計されている理由を、鍵のロールオーバー(更新)のしやすさという観点から説明してください。
2. Authentication・Encryption・Authenticated Encryptionの3サービスのうち、「Encryption(暗号化のみ)」が実運用での採用例が限定的である理由を、暗号文が改ざんされた場合に受信側が検出できるかどうかという観点から説明してください。
3. あるミッションが、TCフレームにAuthenticated Encryption(AES-GCM相当)を適用することを検討しています。このとき増加するフレームあたりのオーバーヘッド(Security Header + Security Trailerのビット数)が、TM宇宙データリンクプロトコルの回で見たフレーム長(たとえば1024オクテット)に対して何%程度になるか、IV 96ビット、鍵ID/SPI 16ビット、シーケンス番号16ビット、MAC 128ビットという想定値を使って概算してください。
4. すでに打ち上げられ運用中の探査機に対して、SDLSのようなセキュリティ機能を軌道上で新たに有効化することがなぜ難しいか、この回で挙げた「帯域」「搭載処理能力」「既存プロトコルとの互換性」「鍵管理の運用コスト」という4つの観点のうち、あなたが最も本質的だと考えるものを1つ選び、理由とともに論じてください。

まとめと次回予告

コマンド認証の回で学んだMACの原理と、TM宇宙データリンクプロトコルの回で学んだトランスファーフレームの構造は、それぞれ独立した抽象概念でした。この回では、CCSDS 355.0-B (SDLS) が、既存のフレームフォーマットのデータフィールド内側に Security Header(鍵ID/SPI・IV・アンチリプレイカウンタ)と Security Trailer(MACタグ)という2つのフィールドを挿入することで、この2つを具体的にどう縫い合わせるかを標準化していることを見ました。Authentication・Encryption・Authenticated Encryptionという3つのサービスは、ミッションの機微性と搭載資源の余裕に応じて選択され、SPIによる間接参照が鍵の世代管理(ロールオーバー)をフレームフォーマットを変えずに実現していました。一方で、帯域・搭載処理能力・既存プロトコルとの互換性という現実的な制約から、SDLSの全面的な普及にはまだ時間がかかる現状も確認しました。

次回は、この鍵管理の話題をさらに先に進め、共有鍵をどう安全に配送するかという課題に対する将来技術として、衛星量子鍵配送(Satellite QKD) に軽く触れます。物理法則そのものに基づいて盗聴を検知するという、これまでの計算量的安全性(暗号解析が現実的な時間では不可能という前提)とはまったく異なる安全性の考え方が、宇宙リンクにどう応用されうるかを見ていきます。

参考文献

• CCSDS 355.0-B, Space Data Link Security Protocol, Blue Book
• CCSDS 350.9-G, Space Data Link Security Protocol — Extended Procedures, Green Book
• CCSDS 132.0-B, TM Space Data Link Protocol
• CCSDS 232.0-B, TC Space Data Link Protocol
• NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
• CISA/NIST, Foundational Practices for Space Systems Cybersecurity
• J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD