應用CCSDS空間數(shù)據(jù)鏈路安全協(xié)議的衛(wèi)星遙控安全方案探討

陳杰 熊曉將 陳亮亮 齊海銘

(中國空間技術研究院通信衛(wèi)星事業(yè)部,北京 100094)

隨著我國通信衛(wèi)星的出口，以東方紅四號平臺為代表的國產通信衛(wèi)星逐漸邁向歐洲、美洲等成熟的運營商市場。成熟運營商對測控協(xié)議設計和運行管理提出了更為苛刻的要求，如衛(wèi)星用戶對衛(wèi)星測控系統(tǒng)的遙控功能應采用空間數(shù)據(jù)系統(tǒng)咨詢委員會(CCSDS)標準，同時要采用高級加密標準(AES)加密標準實現(xiàn)對遙控數(shù)據(jù)的安全保護。然而，國內衛(wèi)星普遍采用脈沖編碼調制(PCM)遙控體制，加解密算法也是基于任務需求的專用算法，沒有基于某一個通用標準開展加解密系統(tǒng)設計。

隨著衛(wèi)星復雜度和類型的增加，衛(wèi)星任務的物理環(huán)境更為復雜，現(xiàn)行相關標準已無法完全支持新技術發(fā)展的要求，因此需要開展與CCSDS標準對標和國家相關標準制定的工作。而對于CCSDS安全協(xié)議標準，若有類似文獻[1]中的應用實例，即針對每種指令數(shù)據(jù)類型給出協(xié)議的任務配置數(shù)據(jù)及遙控流程，其易用性會大大提升。同時，隨著近些年CCSDS安全協(xié)議發(fā)展，目前CCSDS安全協(xié)議體系已較為完善，從總則[2]、協(xié)議[3]、算法[4]、密鑰管理[5]到擴展流程[6]，已能夠全面支持衛(wèi)星在軌應用。文獻[7]中對CCSDS空間數(shù)據(jù)鏈路安全協(xié)議[3]進行了詳細介紹，并且對該協(xié)議在國內空間任務中應用提出了若干建議，但對CCSDS空間數(shù)據(jù)鏈路安全協(xié)議的應用參考價值不大，無法指導安全協(xié)議系統(tǒng)的實際設計。文獻[8-9]中研究了加密認證算法應用于CCSDS分包遙控數(shù)據(jù)鏈路層的性能，并且基于OPNET仿真平臺，給出了性能分析，但僅僅給出了采用AES/SHA-256/GCM算法的數(shù)據(jù)加解密結果,同樣無法指導安全協(xié)議系統(tǒng)的實際設計。

本文針對國內衛(wèi)星遙控數(shù)據(jù)安全保護和遙控體制國際化的需求，應用CCSDS空間數(shù)據(jù)鏈路安全協(xié)議，設計了一套遙控安全方案，并且針對該遙控安全方案給出了應用實例,針對該應用實例進行了定性仿真驗證分析,有助于CCSDS安全協(xié)議的應用和本地化，可為我國衛(wèi)星遙控體制與國際接軌提供參考。

1 遙控安全方案設計

本文的遙控安全方案選擇在數(shù)據(jù)鏈路層實現(xiàn)數(shù)據(jù)保護機制，數(shù)據(jù)保護對象為傳送幀。由于數(shù)據(jù)鏈路層位于傳送層和信道編碼層之間，在數(shù)據(jù)鏈路層實施數(shù)據(jù)保護具有操作簡單的優(yōu)點。因此，在安全協(xié)議的選擇上，本文遙控安全方案使用CCSDS空間數(shù)據(jù)鏈路安全協(xié)議[3]。在安全業(yè)務的選擇上，采用的安全業(yè)務為認證和加密認證，選用的算法為基于密文的消息認證碼(CMAC)[10]和Galois/計數(shù)器模式(GCM)[11]，分別對應認證和加密認證業(yè)務。

1.1 安全協(xié)議定制

空間數(shù)據(jù)鏈路安全協(xié)議的應用，重點在于其數(shù)據(jù)格式與算法的匹配。本文遙控安全方案選用CMAC和GCM分別作為認證和加密認證業(yè)務算法，針對這兩種安全業(yè)務的格式定制如圖1～3所示。表1為安全頭字段意義，對于認證業(yè)務，使用CMAC算法，在安全頭中不需要“初始向量”和“填充長度”數(shù)據(jù)域，因此安全頭長度為48 bit。安全尾(消息認證碼(MAC))的長度為128 bit。對加密認證業(yè)務使用GCM算法，通常采用簡單的加法計數(shù)器作為初始向量(IV)，不需要設置單獨的防重放序列號，因此安全頭長度為112 bit。安全尾與認證業(yè)務的安全尾一致。

圖1 采用CMAC算法的安全頭Fig.1 Security header (CMAC algorithm)

圖2 安全尾Fig.2 Security trailer

圖3 采用GCM算法的安全頭Fig.3 Security header (GCM algorithm)

表1 安全頭字段意義

Table 1 Field meaning of security header

字段名稱字段意義SPI用于標志安全關聯(lián)(SA)的索引IV對于應用加密認證業(yè)務的系統(tǒng)而言,可作為計數(shù)器序列號包含防重放序列號,用于防重放攻擊填充長度算法處理中填充字節(jié)的總長度,為字節(jié)的整數(shù)倍

1.2 業(yè)務管理

1.2.1 SA管理

SA的概念來自互聯(lián)網安全協(xié)議(IPSec)，是2個應用IPSec系統(tǒng)(主機、路由器)間的一個單向邏輯連接，是安全策略的具象化和實例化，它給出了保護通信的具體細節(jié)。在空間通信應用中，需要對其進行修改，以適應空間通信的特點。在CCSDS空間數(shù)據(jù)鏈路安全協(xié)議[3]中指出，發(fā)送端和接收端都必須創(chuàng)建1個SA，在SA使用前將其和密鑰進行關聯(lián)，并激活密鑰。多個SA的參數(shù)可以在衛(wèi)星發(fā)射前進行靜態(tài)定義。如果需要，SA的參數(shù)也可以動態(tài)創(chuàng)建，甚至在其他SA生效時也可以創(chuàng)建。SA間的激活狀態(tài)切換機制在應用層進行實現(xiàn)，協(xié)商SA參數(shù)屬于應用層的功能。

針對上述需求，本文遙控安全方案選用下述SA管理業(yè)務[6]，實現(xiàn)SA的在軌管理工作。①啟動SA(SA Start)：開始使用信道上特定的SA；②停止SA(SA Stop)：停止使用信道上特定的SA；③密鑰更新(SA Rekey)：在激活SA之前將密鑰與SA相關聯(lián)；④SA到期(SA Expire)：將原密鑰與原SA去關聯(lián)；⑤新建SA(SA Create)：根據(jù)業(yè)務用戶提供的參數(shù)初始化SA；⑥刪除SA(SA Delete)：完整刪除1個SA；⑦設置防重放計數(shù)器(SA SetARC)：根據(jù)業(yè)務用戶提供的值初始化SA的防重放序列號；⑧設置防重放窗口(SA SetARCW)：根據(jù)業(yè)務用戶提供的值初始化SA的防重放窗口；⑨查詢SA狀態(tài)(SA Status)：查詢SA當前狀態(tài)。

本文遙控安全方案選取SA的4種狀態(tài)，即無SA狀態(tài)(NULL)、未與密鑰關聯(lián)狀態(tài)(Unkeyed)、與密鑰關聯(lián)狀態(tài)(Keyed)及SA運行狀態(tài)(Operational)。從圖4中可以看到，通過SA管理指令，即可實現(xiàn)SA狀態(tài)的轉換，其中“設置防重放計數(shù)器”、“設置防重放窗口”、“查詢SA狀態(tài)”3項SA管理業(yè)務不會引起SA狀態(tài)的轉換。

圖4 安全關聯(lián)管理的狀態(tài)模型Fig.4 State model for security association management

1.2.2 算法管理

本文遙控安全方案采用的CMAC和GCM均為對稱密碼算法，即星地使用的密鑰相同。針對CMAC算法，對于一段需要被驗證的消息M，有2種操作，如圖5所示。AES-K是帶密鑰K的AES算法。消息M被分成M_1,M_2,…，M_n，除了M_n，前面每塊長度等于128 bit。最后一塊M_n的長度，不大于128 bit。K1是圖5(a)所用子密鑰；K2是圖5(b)所用子密鑰。K1和K2由子密鑰生成算法生成。如果輸入消息塊的尺寸等于128 bit的整數(shù)倍，最后的塊將和K1異或；否則，最后的塊將被填補10∧i(表示“1”后補i個“0”)，使其長度等于128 bit，然后和K2異或。上述過程的結果將是最后加密操作的輸入。CMAC的輸出T(即安全尾)為整個輸入消息M提供了數(shù)據(jù)完整性。星上的解密過程就是將安全尾重算一遍，比較計算結果是否與收到的安全尾結果一致：一致，則通過驗證；否則，驗證無效。CMAC算法詳見文獻[10]。

圖5 CMAC算法流程

針對GCM算法，同樣需要將明文P按照128 bit分組，用n和u表示明文總長度為(n-1)×128+u，1≤u≤128。即明文由一系列的n組數(shù)據(jù)組成，最后一組數(shù)據(jù)長度為u,其他長度均為128 bit。這些明文數(shù)據(jù)塊記為P1,P2,P3,…,Pn-1,Pn。密文C的數(shù)據(jù)塊記為C1,C2,C3,…,Cn-1,Cn。Pn和Cn的長度均為u。附加鑒別數(shù)據(jù)A的數(shù)據(jù)塊記為A1,A2,…,Am-1,Am。Am長度為v，A總長度為(m-1)×128+v，1≤v≤128。這里附加鑒別數(shù)據(jù)的含義是需要用于進行認證但不需要進行加密的數(shù)據(jù)。CIPHK是帶密鑰K的AES算法。inc是遞增函數(shù)；J0為IV|0311，表示IV和0311(即31個“0”與1個“1”級聯(lián)組成的比特序列)級聯(lián)；MSBt為截取某序列最左邊t個比特的序列；[len(·)]64為返回64 bit的數(shù)據(jù)串長度；GCTRK和GHASHH為特殊函數(shù)，GCTRK表示AES計數(shù)器模式運算，GHASHH表示加密哈希函數(shù)運算，2個函數(shù)的定義詳見文獻[11]。

按照圖6(a)所示的流程，即可完成數(shù)據(jù)加密認證。按照圖6(b)所示的流程，即可完成數(shù)據(jù)的解密認證。比較計算得到的T′與收到的T的字符串：一致，通過驗證；否則，驗證無效。GCM算法詳見文獻[11]。

圖6 GCM算法流程

1.2.3 密鑰管理

本文遙控安全方案對密鑰進行分層控制[5]，分為主密鑰和會話密鑰。其中，主密鑰為最高等級密鑰，一般在衛(wèi)星發(fā)射前通過安全信道固化在衛(wèi)星存儲器中。主密鑰又可進一步細化為密鑰加密密鑰，用于加密或加密認證會話密鑰，或者用于會話密鑰的生成，或者用于加密或加密認證指定的星上加解密單元指令和流程。會話密鑰，又稱為數(shù)據(jù)加密密鑰，為最低等級密鑰，用于保護衛(wèi)星的通信信道，實現(xiàn)加密、認證或其他類型業(yè)務。

對于密鑰生命周期，選取如下4個狀態(tài)[12]。①預激活態(tài)(Pre-Activation)：剛生成的密鑰應處于預激活態(tài)；②激活態(tài)(Active)：進入激活態(tài)的密鑰應開始其工作生命周期；③去激活態(tài)(Deactivated)：密鑰已處于其工作生命周期的終點，但未被毀壞；④毀壞態(tài)(Destroyed)：密鑰已處于其工作生命周期的終點，且被毀壞。針對上述密鑰生命周期，采用如圖7所示的密鑰管理業(yè)務。

圖7 密鑰生命周期Fig.7 Cryptographic key lifecycle

實現(xiàn)密鑰生命周期的管理包括以下幾個方面。①無線密鑰更新(OTAR)：將新會話密鑰從發(fā)起者安全傳送至接收者；②激活密鑰(Key Activation)：激活通信兩端的密鑰，使密鑰處于激活態(tài)，可用于加解密操作；③去激活密鑰(Key Deactivation)；去激活通信兩端的密鑰，使密鑰處于去激活態(tài)，不可用于加解密操作；④毀壞密鑰(Key Destruction)：刪除通信兩端的密鑰；⑤密鑰認證(Key Verification)：對接收端的處于激活態(tài)的會話密鑰進行認證。

2 實例驗證

2.1 驗證系統(tǒng)

本文遙控安全方案可由計算機和目標機搭建的驗證系統(tǒng)，基于典型應用場景進行驗證，其中計算機模擬地面站，目標機模擬目標衛(wèi)星的遙控單元，各設備均配置本文設計的遙控安全協(xié)議。驗證系統(tǒng)配置3層密鑰進行控制，即主密鑰、密鑰加密密鑰和會話密鑰。其中：主密鑰用于傳送密鑰加密密鑰和應急恢復；密鑰加密密鑰用于傳送會話密鑰；會話密鑰用于上傳日常指令和數(shù)據(jù)。

驗證系統(tǒng)設置如下4個SA用于衛(wèi)星在軌操作。①SA1：key用作主密鑰，采用加密認證業(yè)務，SPI為0x0001，MAP63；②SA2：key用作密鑰加密密鑰，采用加密認證業(yè)務，SPI為0x0002，MAP1；③SA3：key用作會話密鑰，采用認證業(yè)務，SPI為0x0003，MAP2；④SA4：key用作會話密鑰，采用認證業(yè)務，SPI為0x0004，MAP0。其中：SA1的所有信息存儲在目標機的Flash中；SA2～SA4的所有信息存儲或創(chuàng)建在目標機的靜態(tài)隨機存取存儲器(SRAM)中。另外，SA3用于數(shù)據(jù)注入，而SA4用于直接指令。

2.2 驗證結果

以上述驗證系統(tǒng)環(huán)境為基礎，設計主控計算機向目標機上注遙控指令的實例。這里考慮2種應用場景：①對衛(wèi)星進行日常操作，包括數(shù)據(jù)上注和指令上注，對數(shù)據(jù)/指令認證后上傳衛(wèi)星，見圖8；②對衛(wèi)星進行應急操作，包括密鑰上注，對密鑰加密認證后上傳衛(wèi)星，見圖9。

注：CRC為循環(huán)冗余校驗；M(X)為CRC編碼中輸入的數(shù)據(jù)塊，G(X)為生成多項式，L(X)為預置多項式。圖8 發(fā)送端遙控認證業(yè)務Fig.8 TC authentication operation of sending end

圖9 發(fā)送端遙控加密認證業(yè)務Fig.9 TC authenticated encryption operation of sending end

對于場景①，發(fā)送端的數(shù)據(jù)/指令流轉過程如下，接收端的數(shù)據(jù)/指令流轉過程相反。

(1)用戶數(shù)據(jù)/指令進行包封裝；

(2)根據(jù)用戶數(shù)據(jù)/指令類型選擇SA，按照本文設計的安全協(xié)議進行認證載荷封裝；

(3)將認證載荷及密鑰送入CMAC算法，得到安全尾；

(4)按照遙控數(shù)據(jù)鏈路協(xié)議進行傳送幀封裝；

(5)將傳送幀送入編碼子層進行BCH(63,56)編碼后，組成通信傳送單元(CLTU)送入物理層傳輸。

對于場景②，發(fā)送端的數(shù)據(jù)/指令流轉過程如下，接收端的數(shù)據(jù)/指令流轉過程相反。

(1)用戶數(shù)據(jù)/指令進行包封裝；

(2)根據(jù)用戶數(shù)據(jù)/指令類型選擇SA，按照本文設計的安全協(xié)議進行認證載荷封裝；

(3)將認證載荷、IV、加密載荷、密鑰送入GCM算法，得到密文和安全尾；

(4)按照遙控數(shù)據(jù)鏈路協(xié)議進行傳送幀封裝；

(5)將傳送幀送入編碼子層進行BCH(63,56)編碼后，組成CLTU送入物理層傳輸。

從上述2個應用場景的驗證中可以看到：本文遙控安全方案能夠實現(xiàn)衛(wèi)星在軌正常操作和應急操作，同時具備衛(wèi)星在軌安全關聯(lián)和密鑰管理能力。該方案側重于協(xié)議和功能的實現(xiàn)與驗證，但受限于當前驗證系統(tǒng)的資源和軟件實現(xiàn)的復雜度，還無法支持性能測試，因此僅從定性角度進行了驗證和分析，沒有定量試驗結果展示。

從本文遙控安全方案的應用效果來看，主要有以下優(yōu)點。①通過SA管理，可以使遙控數(shù)據(jù)安全保護機制更為靈活，既可以建立不同SA與虛擬信道的關系，針對不同遙控數(shù)據(jù)實現(xiàn)不同的安全業(yè)務，又完全不影響原有數(shù)據(jù)的保護策略，可顯著提高遙控安全系統(tǒng)的靈活性、可擴展性。②利用密鑰分層結構，可以保護密鑰強度，延長密鑰生命周期；同時，也可實現(xiàn)密鑰在軌靈活管理，將更多的自主權交給衛(wèi)星用戶，提升衛(wèi)星的好用易用性。

3 結束語

在遙控體制與國際接軌的背景下，本文在調研CCSDS測控協(xié)議體系的基礎上，針對不同的遙控安全業(yè)務，分別設計了定制遙控幀格式、安全關聯(lián)、算法管理及密鑰管理業(yè)務，并在地面驗證系統(tǒng)中通過2個典型應用場景仿真驗證了該方案具備在軌保護遙控數(shù)據(jù)安全的可行性。后續(xù)將繼續(xù)完善地面驗證系統(tǒng)，并在地面驗證系統(tǒng)中進行定量仿真驗證分析，為我國測控體制與國際接軌提供支持。