余志浩

城市軌道交通基于通信的列車控制系統(tǒng)（CBTC）,是信息物理系統(tǒng)（CPS）在安全關鍵領域的典型應用之一。該系統(tǒng)信號傳輸部分的安全性（包括信號本身的真實性、完整性、實時性及信息安全）一直是行業(yè)內(nèi)比較關注的問題。本文將對CBTC系統(tǒng)信號傳輸部分的安全性進行剖析,對相關安全需求進行闡述,以分析其信號傳輸部分是否安全,是否能夠在所要求的安全級別下防范住相應的環(huán)境干擾、傳輸設備影響,以及人為的有意或無意的入侵或破壞。

本文將CBTC系統(tǒng)信號傳輸部分單獨作為一個子系統(tǒng)進行分析,稱之為傳輸系統(tǒng)。對該傳輸系統(tǒng),按照層次位置劃分,將從板間傳輸系統(tǒng)開始,逐步上升至子架間、柜間傳輸系統(tǒng),每一層級上采用故障樹（FTA）定性分析方式。本文未進行詳細的板內(nèi)傳輸系統(tǒng)（如片總線、片內(nèi)總線、系統(tǒng)總線等）分析,但提供了一種板內(nèi)傳輸系統(tǒng)的安全保證策略。

1 傳輸系統(tǒng)分類

每個安全關鍵系統(tǒng)都會按照各自的安全相關硬件需求搭建不同的硬件架構,并進行相應的功能模塊劃分,如圖1所示的系統(tǒng)架構。本文主要將主板分為內(nèi)核、自檢/監(jiān)督單元、接口等模塊,它們共同組成一個計算組件（CE）,如圖1中的計算組件A。2個計算組件構成一個邏輯意義上的計算節(jié)點（CN）,節(jié)點內(nèi)2個組件之間存在數(shù)據(jù)交互；計算節(jié)點與外圍設備存在數(shù)據(jù)交互。計算節(jié)點和外圍設備構成子系統(tǒng),子系統(tǒng)之間也存在數(shù)據(jù)交互。

圖1 系統(tǒng)架構

本文定義,計算節(jié)點內(nèi)2個組件之間的信號交換為板間通信；計算節(jié)點通過總線接口與外圍設備進行的信號交換為子架間通信；子系統(tǒng)通過網(wǎng)絡接口與其它子系統(tǒng)之間進行的信號交換為柜間通信。

典型的傳輸系統(tǒng),其傳輸方式可以分為直接經(jīng)由銅箔材質(zhì)的印制電路板（PCB）點對點傳輸,以及由控制器局域網(wǎng)（CAN）總線傳輸、以太網(wǎng)（Ethernet）網(wǎng)絡傳輸。

PCB點對點傳輸更多的用于板內(nèi)各元件之間電平信號傳輸,其線路分布較為分散,對其進行完備的系統(tǒng)評估比較困難。針對該問題,本文將在后續(xù)第5節(jié)中進行討論。

對于CAN總線傳輸,由于它是事件驅動型的,相比于以太網(wǎng)通信,它的時延更小,更適合外圍設備狀態(tài)信息輸入至內(nèi)核,或內(nèi)核命令輸出至外圍設備等實時性要求較高,且對發(fā)送/接收模塊的配置要求較低的封閉式傳輸場景。因此CAN總線更多的用于板間、子架間的中短報文、短距離應用場景,不適合長報文、長距離通信［1］。

對于以太網(wǎng)網(wǎng)絡傳輸,既可用于板間、子架間報文傳輸,也可用于柜間長報文、長距離通信,但后者通常需要考慮傳輸延時的影響。

下面按照板間、子架間、柜間傳輸系統(tǒng)的順序,依次進行介紹及分析。

2 板間傳輸系統(tǒng)

考慮差異性和功能獨立性等安全設計原則,本文中兩組件之間的板間通信采用以太網(wǎng)網(wǎng)絡連接,以區(qū)別于計算節(jié)點與外圍設備的CAN總線通信方式。

2.1 故障模式分析

GB/T 24339.1［2］中描述封閉式傳輸系統(tǒng)故障模式分別是傳輸硬件故障導致的失效,及由于外部（如EMI）對傳輸介質(zhì)的影響導致的隨機錯誤。

以超五類（CAT.5e）4芯屏蔽線纜為例,其應用及性能需滿足ANSI/TIA/EIA-568-B.1［3］標準要求。板間通信采用基帶傳輸,假定傳輸頻率為100 MHz,傳輸距離為1 m,且底層滿足IEEE 802.3規(guī)范［4］的CSMA/CD協(xié)議。帶有沖突檢測的載波偵聽多路訪問協(xié)議的使用,可以有效防范由于多節(jié)點同時發(fā)送數(shù)據(jù)導致的數(shù)據(jù)錯誤,因此本節(jié)不對此故障模式進行分析,即假定信道上同時只有1個發(fā)送端以及1個接收端。

當數(shù)據(jù)在發(fā)送端,由于非置信傳輸設備的使用,存在發(fā)送端硬件故障或緩存故障導致數(shù)據(jù)生成錯誤,或數(shù)據(jù)被誤刪除,或誤插入其它數(shù)據(jù)；或者發(fā)送端由于緩存了待發(fā)送或已發(fā)送的數(shù)據(jù),導致不受控的重復發(fā)送相同報文,或錯序發(fā)送報文,或非預期的延遲發(fā)送報文。

當“數(shù)據(jù)發(fā)送結束”正在傳播時,由于外部環(huán)境強電磁干擾（如EMI）,存在信號串擾導致數(shù)據(jù)傳輸錯誤的情況。

由于線纜插入損耗、連接硬件插入損耗等因素也會導致數(shù)據(jù)傳輸錯誤,或網(wǎng)絡堵塞導致傳輸延遲,由于板間通信傳輸距離為1 m,因此暫不考慮此2種故障模式。本節(jié)不考慮斷線、短路、接觸不良等故障,應由成熟的線纜接線規(guī)范及工藝來保證線纜連接的可靠性；同時,也不考慮線纜老化等情況。

當數(shù)據(jù)在接收端,由于非置信傳輸設備的使用,存在接收端硬件故障或電壓錯判或緩存故障導致數(shù)據(jù)接收、上傳錯誤,或數(shù)據(jù)被誤刪除,或誤插入其它數(shù)據(jù)；或者接收端由于緩存了已接收或已上報的數(shù)據(jù),導致不受控的重復上傳相同報文,或錯序上傳報文,或非預期的延遲上傳報文。

綜上,對于板間傳輸系統(tǒng),其故障影響及原因分析見圖2。

圖2 板間傳輸系統(tǒng)傳輸鏈路故障樹分析

對故障樹底事件分類,可以得到的原因為發(fā)送/接收端傳輸硬件故障、發(fā)送/接收端緩存錯誤、發(fā)送/接收端設備驅動錯誤、信道環(huán)境干擾。這些故障造成的直接影響是數(shù)據(jù)損壞、誤刪除、誤插入、延遲、重復、錯序,如果這些影響能直接導致不可接受的風險,那么就需要采取措施進行防范。

2.2 安全需求

可通過制定對傳輸系統(tǒng)軟硬件的安全需求,來防范所識別的風險。最簡單的方式是將發(fā)送/接收端傳輸設備做成可信設備,并對數(shù)據(jù)加入安全碼校驗,即可防范傳輸硬件故障、緩存錯誤、設備驅動錯誤及信道環(huán)境干擾導致的風險。

但是,由于開放系統(tǒng)互聯(lián)參考模型（OSI）、相應協(xié)議的制定及設備的設計制造,并未做過功能、技術、質(zhì)量上的評審,其安全完整性等級無法保證,因此對于安全關鍵電子系統(tǒng)的應用,需采用其它方式對相應危害進行防范。

需求1:應采取二取二（2oo2）或三取二（2oo3）等組合式失效-安全架構。

需求2:如果是軟件平臺層面實現(xiàn),應保證用于比對的數(shù)據(jù)長度,滿足預定的安全需求；如果是硬件層面實現(xiàn),應保證用于比對的各方,其來源通道的失效概率組合滿足預定的安全等級。

需求3:應保證2oo2或2oo3等組合式失效-安全架構中參與比對的各方,其來源在物理或功能層面上滿足獨立性、差異性安全需求。

需求4:在應用層應使用長度足夠的安全碼,如循環(huán)冗余校驗碼（CRC）,以實現(xiàn)對信道干擾的誤碼探測。

需求5:應保證參與比對的數(shù)據(jù)時效性、有序性需求,相應的關鍵時序分析應包含在系統(tǒng)安全論據(jù)內(nèi)。

對于任何安全相關數(shù)據(jù),均需做到“輸入—比對—處理—比對—輸出”流程,其中“比對”與“處理”是每個計算組件里面內(nèi)核、自檢/監(jiān)督單元執(zhí)行的操作,需要2路獨立數(shù)據(jù)來源。該板間通信鏈路提供了某個外圍設備的兩路比對數(shù)據(jù)中的其中一路數(shù)據(jù)來源,而另一路則通過CAN網(wǎng)絡直接來源于該外圍設備。

對于信道干擾導致的數(shù)據(jù)傳輸錯誤,需在內(nèi)核處理上采用足夠長度的安全碼進行校驗,而線纜屏蔽層的正確使用,可以有效減少信道誤碼率,提升系統(tǒng)可用性；傳輸數(shù)據(jù)中需增加序列號,以確保數(shù)據(jù)的有序性。

到目前為止,所有已應用的CBTC安全操作系統(tǒng)平臺都采用了以上需求1所描述的架構,且都直接或間接符合了需求1至需求5的規(guī)定,以滿足GB/T 28809［5］中最高安全完整性等級要求,并通過了有資質(zhì)的獨立第三方安全評估（ISA）機構的安全評審。

3 子架間傳輸系統(tǒng)

典型的子架間傳輸系統(tǒng),以CAN總線通信作為計算組件與外圍設備之間的通信方式。CAN總線通信采用串行通信協(xié)議,物理層使用BOSCH CAN2.0協(xié)議,數(shù)據(jù)鏈路層滿足ISO 11898規(guī)范［1］,它與板間通信所使用的以太網(wǎng)協(xié)議有較大差異,報文結構也不同。

為避免相互影響,每個計算組件會獨立提供與外圍設備的通信通道。因此,對于計算組件A及計算組件B,其CAN總線并不共享,即該子架間通信仍然是點到點的封閉傳輸系統(tǒng)。

由于CAN總線通信協(xié)議中無損仲裁技術的使用,可以有效防范由于多節(jié)點同時發(fā)送數(shù)據(jù)導致的數(shù)據(jù)錯誤,因此本節(jié)不對此故障模式進行分析,即假定信道上同時只有一個發(fā)送端以及一個接收端。

對于該子架間傳輸系統(tǒng),它在數(shù)據(jù)發(fā)送端及數(shù)據(jù)接收端,同樣是非置信傳輸設備的使用及其所導致的故障情形,數(shù)據(jù)傳輸環(huán)境也存在強電磁干擾（如EMI）導致的數(shù)據(jù)傳輸錯誤的情況,因此其后續(xù)安全分析與板間以太網(wǎng)的分析類似,故障模式相同,相應的安全需求可以復用。

4 柜間傳輸系統(tǒng)

柜間傳輸系統(tǒng)一般指不同子系統(tǒng)之間長距離、多點的數(shù)據(jù)傳輸。以柜間傳輸系統(tǒng)采用以太網(wǎng)（含無線傳輸）通信協(xié)議為例進行分析。

在主板上的網(wǎng)絡接口層面,柜間傳輸系統(tǒng)與板間傳輸系統(tǒng)并無差異,如均采用Linux內(nèi)核自帶的以太網(wǎng)接口,其物理層、鏈路層、網(wǎng)絡層均保持一致。本節(jié)僅針對差異部分進行分析。

對于差異部分,由于長距離的使用場景,引入了傳輸中繼器件,如交換機、路由器、長線纜或光纖等,這些中間設備均為非置信傳輸設備；而無線通信場景,則引入了eNodeB、天線等設備,如射頻拉遠單元（RRU）、基帶處理單元（BBU）等非置信無線傳輸設備,以及介質(zhì)特性不穩(wěn)定、通信參與方不受管制的空口無線傳輸信道。

4.1 故障模式分析

傳輸中繼器件帶來的故障影響,與前述非置信設備帶來的影響相比并無差異,因此相應的安全需求可以復用,但是故障來源中新增了中繼器硬件故障或相應的軟件錯誤這一故障原因。同時,由于無線信道的引入,外部非授權人員可以隨時入侵CBTC系統(tǒng)控制網(wǎng)絡,偵聽、篡改或偽裝安全數(shù)據(jù),導致系統(tǒng)可能出現(xiàn)不可預知行為的風險,這是不被接受的,且通信參與方也無法固定,因此柜間傳輸系統(tǒng)需考慮數(shù)據(jù)傳輸過程的信息安全（IS）。對于柜間傳輸系統(tǒng),其故障影響及原因分析見圖3。

圖3 柜間傳輸系統(tǒng)傳輸鏈路故障樹分析

對故障樹底事件分類,可以得到的原因為發(fā)送端/接收端及中繼傳輸硬件或軟件故障、信道干擾,或人為入侵、破壞。這些故障造成的直接影響是數(shù)據(jù)損壞、誤刪除、誤插入、延遲、重復、錯序、被篡改或偽造,如果這些影響能直接導致不可接受的風險,那么就需要采取措施進行防范。

4.2 安全需求

對于P2-1、P2-2事件,相應的安全需求如前述需求1至需求5,由通信雙方計算節(jié)點的軟硬件架構和設計滿足。對于P2-3事件,信號系統(tǒng)需達到一定的信息安全等級,并符合GB/T 24339.2規(guī)范［6］,因此新增以下安全需求。

需求6:應保證系統(tǒng)符合一定的信息安全等級保護要求,且對于開放式傳輸系統(tǒng)應提供信息加密,加密算法應保證被傳輸數(shù)據(jù)不會在合理時間內(nèi)被破解。

需求7:系統(tǒng)物理設備設置的外部可接入串口、網(wǎng)口等接口應嚴格管理,確保不被人為或病毒入侵。

需求8:傳輸系統(tǒng)參與方應有源與目的標識,并做校驗。

CBTC系統(tǒng)傳輸模塊的信息安全要求,是包含在第三方獨立安全評估機構認證范圍內(nèi)的,以符合GB/T 28809［5］中最高安全完整性等級要求。同時,依據(jù)GB17859［7］,CBTC系統(tǒng)仍需符合信息安全等級保護三級防護要求。

與其它六類影響一樣,被篡改或偽裝的數(shù)據(jù)也會直接給系統(tǒng)帶來嚴重的危害,信息安全防護是必要的,且需要長期跟進并隨著相關技術演進而不斷優(yōu)化。例如鐵路行業(yè)中使用廣泛的鐵路信號安全通信協(xié)議RSSP-II,目前理論上已存在被破解的可能,其信息安全性分析可參見文獻［8］。建議盡快采用國際或國內(nèi)標準化的128 b分組密碼（如AES或SM-4）替換現(xiàn)有的64 b分組密碼DES。

5 板內(nèi)傳輸系統(tǒng)安全保證策略

內(nèi)核運行時會執(zhí)行各種任務,某些關聯(lián)任務會共同組成一個任務組,內(nèi)核以此為最小單元（進程）執(zhí)行相應的計算與決策。這些任務組有的是安全相關的,有的是非安全的。對于安全任務組,平臺層面需對其硬件錯誤（如內(nèi)存錯誤）進行監(jiān)督與保護,而任務組之間的通信也應加以防護。

圖1中每個計算組件的內(nèi)核中同時運行著多個任務組,對于執(zhí)行安全關鍵決策的任務組,其來自其它任務組的輸入數(shù)據(jù)在使用前需執(zhí)行2oo2或2oo3等組合式失效-安全計算處理,其輸出數(shù)據(jù)在輸出至接口前也需進行類似計算,以保證:①其它任務組傳輸過來的數(shù)據(jù)是安全的；②自身發(fā)出的命令是安全的。

采用邏輯形式的任務組方式對內(nèi)核里面的數(shù)據(jù)傳輸進行安全管理,是一種可被接受的方式,但在平臺層面仍需對參與比對的消息隊列的時效性、同步性進行管理,并需對輸入消息執(zhí)行相應的安全碼校驗、源/目的信息校驗,即需滿足需求1至需求5及需求8。同時,出于硬件鑒證需求及可靠性要求,主板設計及運行環(huán)境也需滿足相應規(guī)范,如EN 50124-1［9］及EN 50124-2［10］。

6 結論

本文將CBTC系統(tǒng)傳輸部分單獨作為一個子系統(tǒng)進行分析,從板間傳輸系統(tǒng)、子架間傳輸系統(tǒng)、柜間傳輸系統(tǒng)逐層展開,每一層級上采用故障樹定性分析方式,并提出了板內(nèi)傳輸系統(tǒng)安全保證策略。綜合本文分析,可得出每個層級的傳輸系統(tǒng)所面臨的故障模式及與之對應的安全需求。

在滿足文中所列安全需求,且滿足其它必要的行業(yè)規(guī)范后,在所要求的安全級別下,信號系統(tǒng)數(shù)據(jù)傳輸部分能夠防范相應的環(huán)境干擾、非置信傳輸設備的影響,以及人為的有意或無意的入侵、破壞所帶來的相應風險。