基于EN50159標準的智慧車站監控系統安全通信機制

李佑文 俞 銘 陸知言

南京國電南自軌道交通工程有限公司

0 引言

目前，國內外大量城市在進行地鐵智慧車站試點工作，其中，智慧車站監控系統是車站運行管理的核心，是智慧的“大腦”，其實施的目標是實現車站運營數字化、智能化，幫助車站站務人員更加智能地進行站務處理、設備管理，使車站運維更加安全、高效。城市軌道交通一旦遭到破壞，會嚴重危害公共利益，車站作為大中型城市的參與主體，其安全問題更加不容忽視，因此，在車站運行的智慧車站監控系統設計時，必須將安全性放在首位。

智慧車站監控系統集成了多個自動化專業子系統，與眾多子系統利用接口進行數據交互，在B/S架構的智慧車站監控系統中，最關鍵、要求最高的功能是保證通信的安全性。本文設計了一種符合EN50159標準的智慧車站監控系統安全的通信機制，該機制滿足安全完整性等級（Safety Integrity Level，SIL）的2級安全認證。

1 基于SSL加密的WEBSOCKET通信

由于B/S架構屬于完全瘦客戶端特性，不需要在工作站上安裝特定的客戶端軟件就能訪問數據，越來越多的工業控制軟件從C/S架構轉變為B/S架構。為了安全起見，早期的B/S架構客戶端和服務器端無法保持長連接通信，且服務端也法直接推送數據至客戶端，使得工業控制領域數據傳輸的實時性變得很差。為了解決這種矛盾，在智慧車站監控系統的工作站和服務器之間設計一種WEBSOCKET通信機制，與傳統C/S架構下的SOCKET方式類似，能夠保證通信鏈路的長連接，并且工作站和服務器端的通信是完全雙工的，可以相互之間發送數據。

WEBSOCKET本質上是一種計算機網絡應用層的協議，用來彌補HTTP協議在持久通信能力上的不足，由于HTTP本身是無狀態協議，每一個新的HTTP請求只能通過客戶端主動發起，通過建立連接→傳輸數據→斷開連接的方式來傳輸數據，而采用WEBSOCKET通信使得B/S架構的工作站和服務器之間的數據交換變得簡單，允許服務器端主動向客戶端推送數據。使用WEBSOCKET可以創建持久性連接，并進行雙向數據傳輸。

單純的WEBSOCKET數據是不加密的，很容易被竊取。為了保護數據安全，在智慧車站監控系統的工作站與服務器端采用SSL+WEBSOCKET協議的通信方式，其在TCP層對所有交互報文進行加密，工作站只有在安裝了證書的情況下，才能正常訪問服務器，否則會提示連接不安全，需要用戶安裝有效證書后才能訪問服務器。使用證書的SSL+WEBSOCKET方式要求服務器與工作站之間的訪問均受信任，在TCP層保證了通信過程中數據不被泄密和篡改。

2 基于EN50159的安全通信協議設計

雖然在TCP層使用了安全的WEBSOCKET通信機制，但在專用SIL2等級認證的系統中仍然不夠，還需在應用層進行EN50159標準的合規性設計。該標準是專門針對鐵路信號系統中安全相關通信而設立的，從功能和技術層面提出傳輸系統可能遇到的威脅及安全要求和措施。為防御各種風險，其要求通信系統必須在應用層采用規定的防護措施，以提供安全保障。核心思想是通過技術手段保證通信報文的真實性、完整性、實時性和有序性。EN50159標準所規定的7種威脅和8種防護措施如表1所示。

為滿足SIL2級認證要求，智慧車站監控系統中工作站和服務器之間的通信必須在應用層符合EN50159標準，因此，本文針對表1中的8種防護措施進行了對應性的設計。

表1 EN50159標準中的威脅與防護措施

（1）防護措施1：序列號設計。由于WEBSOCKET的全雙工特性，為服務端和客戶端的每條報文均設計發送序列號SendSeqNo和接受序列號RecvSeqNo。

SendSeqNo：unsigned int，每發送一幀報文增加1；

RecvSeqNo：unsigned int，每接受到一幀報文增加1；

客戶端的接受序列號RecvSeqNo應等于服務端的發送序列號SendSeqNo；

服務端的接受序列號RecvSeqNo應等于客戶端的發送序列號SendSeqNo；

（2）防護措施2：時間戳。為每條報文設計一個時間戳SendTime（unsigned long），為了節省傳輸報文的長度，不使用“YYYY-MM-dd HH:mm:ss”格式，而使用4字節時間戳。

（3）防護措施3：超時判斷。設計最大超時時間為Tmax，接收端須校驗兩個報文間的時間間隔是否超過允許的最大時間Tmax，如超過，則視為傳輸發生了錯誤。另外，在無業務數據交互時，通過發送心跳報文來避免超時導致的錯誤。

（4）防護措施4：源、宿標識符。每條報文設計源標識符From，和宿標識符To，分別記錄報文的發送端IP和接收端IP地址，并提前在客戶端和服務器中配置所有可能的源標識IP和宿標識IP，在每次接收到報文后進行IP校驗，從而避免非法IP的模擬報文介入。

（5）防護措施5：反饋報文。不要求每幀請求報文都必須要對應反饋報文，但是在連續收到M（M=8）幀報文后必須反饋，發送端連續發送M幀后會等待反饋報文，若超時后其仍未收到反饋報文，則認為傳輸錯誤。

（6）防護措施6：認證程序。在客戶端和服務端間進行，在客戶端首次連接服務器時發送身份信息（用戶名、密碼）向服務器申請秘鑰Token，服務端身份信息驗證通過后返回Token以及其失效時間，客戶端使用該Token在此段時間內的請求有效，若時間超過，則必須重新申請Token；若服務器端身份驗證信息失敗，則直接拒絕請求。

（7）防護措施7：安全編碼。為每個報文設計個32位的MD5校驗碼字段，用于保存對除了該字段以外的內容進行MD5校驗的值，如圖1所示。

圖1 MD5安全校驗碼設計

（8）防護措施8：加密技術。對所傳輸的報文整體進行加密（不同于MD5的校驗碼），只有授權的用戶，并具有相應的權限才能解密。由于在TCP層已使用SSL加密的WEBSOCKET通信技術，因此，在應用層可以不必再對報文進行加密。

3 結束語

本文在城市軌道交通智慧車站監控系統中使用SSL+WEBSOCKET方式，要求服務器與工作站之間的訪問均是受信任的，在TCP層保證通信過程中數據不被泄密和不被篡改。同時，又在業務應用層對交互的報文進行EN50159標準的合規性設計，通過技術手段保證通信報文的真實性、完整性、實時性和有序性，徹底地解決傳輸系統可能遇到的各種威脅，從而保證通信系統的安全性。