cookieOptions = {...}; ‧ 車聯網時代,汽車網路安全架構如何不“失身” - 3S Market「全球智慧科技應用」市場資訊網

3S MARKET

2014年6月30日 星期一

來源:車雲網

汽車單純地作為通勤工具,能夠聽聽廣播、放放CD就以為是多麼了不起的“多媒體”時代一去不復返了。現如今,汽車可謂是內外連通:不僅能與車內設備連接,同時還可以方便快捷地接入Internet服務。它們通常裝有50-70個電控單元(ECU)來實現行動互聯的不同功能,車內乘客不僅可以隨時從互聯網下載流媒體內容,還可以與朋友們時刻保持聯繫,甚至網上購物也不在話下。

  左:傳統的架構方案-分離式聯網設計 右:以“控制中心”為主的架構方案-集中式的聯網設計
  
當然,凡事都具有兩面性。先進的車載聯網技術,的確可以給用戶帶來便捷的體驗,但不可否認大批的“臭蟲”未來也會順著互聯網這根線索爬進車裡。一輛以直接或者間接方式連接了網際網路的汽車,很可能暴露於惡意軟體的代碼和資料攻擊之下,使車輛受控行駛,急踩刹車,未經允許自動開關車門,甚至會造成類似SRS等重要安全系統的失靈。
  
當然,汽車製造商們也十分“捉急”,而目前看來行之有效的就是建立一套有效的安全系統架構和方法論。
  
以“控制中心”為首的汽車網路安全架構
傳統的汽車網路受限於車內的電控單元,而這些電控單元是與諸如控制器局域網(CAN)、車載網路標準(Flex Ray)及內部互聯網(LIN)等汽車網路相連接的。然而,如今車聯網技術使汽車可實現與提供自動緊急呼叫(e-all)、遠端診斷和資料交換等功能的車內電子設備,和汽車製造商埠進行連接。而在不遠的將來,車與車之間同樣可以自由“交流”,進行作業系統生態資料的無縫交換。
  
隨著資訊娛樂系統和連通性技術的不斷改進,車載資料的密度在本質、數量和方向上發生了很大改變。這些資料可以做如下分類:  
1. 1.接收的資料:汽車通過感測器或互聯網從外部環境中獲得的資料。
傳統的車載軟體僅需要處理ECU通過感測器,或其他電控單元接收的資料即可。然而,ECU設計之初,並不具備檢測每一個CAN上傳資料包的功能。而由於接收的資料一方面包含了從雲端下載的內容,另一方面那些網路連接埠處,惡意軟體植入汽車網路的資料同樣可能包含其中,因此大大增加了汽車網路被“駭”的風險。

2. 2.處理的資料:經ECU不同部分計算處理過的資料,或流經車載娛樂系統ECU的使用者資料群。由於接收到的資料可能並不安全,這可能導致資料處理發生錯誤。同時汽車的聯網和資訊娛樂系統在受到代碼篡改,以及使用者資料人為操控等作用時,很容易出現崩潰。

3. 3.發出的資料:汽車及使用者資料可能需要在雲端處理,以便提供包括個性化投保方案、定制資訊內容以及廣告等眾多服務。
  
隨著汽車與外部設備和外部環境的聯繫愈加緊密,安全風險的本質和以及可能造成的威脅,也正逐漸發生著變化。比如,汽車通過感測器和制動器與環境進行交互。因此,汽車網路的安全,就需要同時考慮資料和環境安全這兩方面因素。而且,對於安全威脅的預防和即時監測同樣需要引起更多的重視。
  
這些潛在風險可分為以下幾種:
1. 1. 安全類:安全性漏洞將削弱關鍵系統的安全性,將乘車人、外部行人和周邊環境置於危險當中。
2. 2. 妨害類非關鍵安全系統受影響,將導致汽車拒絕服務或進行不必要的操作。
3. 3. 隱私類安全性漏洞可能導致個人資訊洩露,並被濫用或篡改。
4. 4. 經濟類經濟損失可能是篡改授權或敲詐勒索等形式。
  
安全性漏洞,隨著允許汽車與外部設備,或網路連接介面數量的增加而逐漸增多。而第一種關鍵的架構方式是:減少介面的數量,並將剩餘的介面整合成一個“控制中心”,而該“控制中心”將作為連通汽車內部網路,和外部設備/網路之間安全、智慧的大門。採用這種方式可以更好地保護汽車不受惡意軟體的攻擊,同時也阻止了敏感資訊的內輸和外露。
  
當然建立以“控制中心”為首的汽車網路安全架構,在應對安全風險時可採取多種策略。如通過設立防火牆的方式來提供對其餘網路的安全訪問。
  
“控制中心”網路安全架構有幾個關鍵要素:
1. 受保護的關鍵入口:基於有線或無線介面的連接;
2. “封閉系統”:提供受限訪問的預配置好的防火牆;
3. 縝密的用戶存取控制:不允許任何非授權使用者訪問隱私資料。
  
汽車網路安全設計方法論
除了靠譜的網路安全系統架構之外,有效的工程解決方案,對於在系統設計的各個步驟中,降低安全風險也是十分關鍵的。汽車製造商及其工程師需要考慮如下的工程方案和設計步驟,來確保汽車網路連接的安全性: 
1. 介面風險分析(Interface risk analysis)
介面風險分析過程,包括檢查所有與汽車連接的雲端,或設備相關的系統介面。第一步是辨識所有的介面終端,包括網路終端、設備和無線介面及匯流排連接器;第二、三步則分別是辨識攻擊以及攻擊中包含的潛在安全問題。一旦介面分析完畢,合適的系統設計方式就可以直接上馬了。
  
2. 功能安全分析(Functional safety analysis)
車輛功能安全標準ISO 26262提供了系統,或子系統內安全要求的方法。其具體描述了諸如危害分析和風險評估、失效模式與影響分析(FMEA)、故障樹分析法以及危害度分析等安全分析的方法。

汽車業應採取功能安全概念來評估安全分析。當安全保障實施完成後,就應該建立含有“證據”的安全狀況報告,囊括安全行為的證據;風險、威脅和漏洞的辨識與分析;以及可服從的安全標準。
  
3. 防禦性程式設計(Defensive programming)
防禦性程式設計,是繼嵌入式安全系統發生關鍵作用之外的推手。它保障了軟體功能即使被用於未預見到的用途時,也能正常運行。在安全環境中,這類未預見到的用途可能來源,於從感測器或汽車網路中接收到的被篡改的資料。防禦性程式設計有這麼幾個特定的操作原則,如“除非能夠證明資料的安全性,那麼所有資料都可能具有傳染性”,即使在惡意輸入的情況下,也能防止軟體發生安全故障,屬於強有力的保護措施。
 
隨著車聯網技術的不斷發展,未來汽車的聯網程度,和內外資料交換的容量都將日益增多。不過要使汽車面對網路惡意攻擊時能夠“刀槍不入”,必須加強汽車安全系統的架構。因此,以“控制中心”為首的汽車安全解決方案,以及強悍的工程方法論,都能夠充分保證汽車在聯網時不致於“失身”。

                                                                                                                                                                                                                            

0 意見: