在過去汽車是一個獨立的系統(tǒng)，相對來說是比較安全，外部也是很難受到相應的攻擊。可是隨著網(wǎng)聯(lián)化的引入，車載OBD、智能充電以及跟OTA系統(tǒng)和藍牙無線的引入，整個系統(tǒng)就不再安全，就需要采用相應的技術(shù)確保車輛的安全。但是在確保整個技術(shù)落地的過程中，需要有相應的工具做相應的開發(fā)和測試。過去在整個系統(tǒng)做開發(fā)的過程中，相關(guān)數(shù)據(jù)“明碼”，并沒有進行加密，所以任何工具都可以拿到相關(guān)的數(shù)據(jù)，可以進行相應的數(shù)據(jù)讀寫，也可以做仿真以及回放。但是在系統(tǒng)通信數(shù)據(jù)加密之后，很多功能沒有辦法做使用常規(guī)工具滿足，如數(shù)據(jù)加密時，簡單的數(shù)據(jù)分析都會遇到很大困擾，然而并不是所有的工具都支持加密系統(tǒng)的開發(fā)和測試。

現(xiàn)在所有用的開發(fā)和測試工具都必須考慮，產(chǎn)品面臨相關(guān)問題時，如何支持Security相關(guān)的應用，尤其是供應商，因為供應商會面對不同OEM的不同項目在不同通信應用層面，各項目各通信層依賴于不同加密體系進行加密，供應商不可能在每個OEM的每個項目都需要采購和學習全新工具鏈。維克多作為車輛網(wǎng)絡(luò)安全的知名供應商，在網(wǎng)絡(luò)安全開發(fā)和測試工具上也有許多自身獨到的經(jīng)驗。 

帶有TLS的DoIP

隨著Ethernet相關(guān)技術(shù)的引入，診斷系統(tǒng)里面采用了DoIP做相應的診斷應用，但是也會隨著安全診斷的考慮，在2019年發(fā)布了新一版的ISO13400-2，這版規(guī)范定義的DoIP通過TLS實現(xiàn)安全診斷。具體流程來看，會在整個通訊過程中，在車輛連接后首先通過13400端口進行Routing激活，在接收到07拒絕響應則表示需要采用TLS進行安全診斷。緊接著測試設(shè)備發(fā)送關(guān)閉傳統(tǒng)的DoIP的13400端口服務，然后進行打開支持TLS的3496端口。然后建立TLS“握手”，實現(xiàn)診斷設(shè)備和ECU或者相應車輛安全密鑰或證書安全通信連接。最后使用再次激活通過TLS協(xié)議，緊接著整個診斷的服務處理都會在TLS協(xié)議下面進行相應的傳輸。

在診斷處理完之后，需要把3496端口進行相應的關(guān)閉處理。在整個流程可以看到，數(shù)據(jù)是有通過TLS實現(xiàn)相應的加密，進行相應的開發(fā)調(diào)試和測試以后，是需要工具能夠支持把DoIP里面的TLS協(xié)議。對于CANoe來說適用內(nèi)嵌的功能能夠完全支持2019版真的DoIP協(xié)議。同時相關(guān)的DoIP配置可以在CANoe里面，通過CANoe自帶的模塊進行相應的配置和處理，當然也可開發(fā)實現(xiàn)TLS本身的協(xié)議測試。與之對應的其它Vector工具，比如維克多的刷寫工具vFlash和診斷儀Indigo都是按照同樣的思路和原理實現(xiàn)TLS的DoIP，目前最新的版本都是能夠支持DoIP的TLS協(xié)議處理。

出口新能源車輛面臨ISO15118的加密充電

車輛互聯(lián)的時候，還有一個重要的接口，就是充電接口。在充電這部分，國內(nèi)目前是使用基于GB/T 27930協(xié)議進行相應的充電處理。但相信國內(nèi)的新能源車企都是有在做車輛出口的業(yè)務，就不得不面臨需要在歐美充電基建體系下進行相應的充電。在歐洲充電體系下中，就需要面對一個重要的規(guī)范：ISO15118。這個協(xié)議本身也一直在做相應的迭代更新，會明顯看到在整個系統(tǒng)里面，隨著新版的15118-20這個協(xié)議的發(fā)布，其中TLS是強制性的要求。

也就是在充電方面，在協(xié)議上面也有相應的加密，在開發(fā)過程中和調(diào)試過程中，無論OEM還是供應商，也不得不依賴相應的工具去解決： ISO15118這個協(xié)議是否支持？在工具和設(shè)備里面，另一個重要的考慮將是剛才提到里面的ISO15118-2和-20中要求的TLS部分，是否能夠完全做相應的支持。

對于充電系統(tǒng)的整個開發(fā)過程，充電部分和實際的傳統(tǒng)開發(fā)流程都是一樣，會有相應的從虛擬SiL原型，到A/B樣以及C樣和量產(chǎn)車，在早期開發(fā)產(chǎn)品的時候，需要模擬充電樁（EVSE）或車輛（EV），因為EV和EVSE之間通信是帶有TLS加密通信，本身充電樁的模擬也要能夠支持TLS的協(xié)議在里面。到后期實際充電的時候，接了真實的樁進行相應的數(shù)據(jù)傳輸，數(shù)據(jù)也有TLS的協(xié)議在里面，一方面數(shù)據(jù)能夠采集下來，另外一方面在分析的時候，解密的工作也是需要工具可以處理的。

無論是以太網(wǎng)還是PLC，數(shù)據(jù)在通訊的時候，在CANoe里面都是能夠把相應的數(shù)據(jù)進行加密和解密的處理。隨著測試完成之后，系統(tǒng)ECU和車輛做集成，集成之后會把車輛跟相應的裝進行數(shù)據(jù)的處理，在里面也是要處理證書，就是TLS方面的一些應用處理。在CANoe中可通過Security Manager模塊實現(xiàn)PKI及其對應證書的處理。

在實測的時候也會提供經(jīng)濟性的方案，方便大家在真實的車和裝之間提取相應的數(shù)據(jù)，做相關(guān)的分析。比如這是真實的車和真實的樁，上邊的通訊數(shù)據(jù)通過PLC進行通訊，數(shù)據(jù)是有加密的，充電過程中的異常數(shù)據(jù)的獲取和分析將是問題。在這邊維克多會提供PLC通訊時的“監(jiān)聽”設(shè)備，進行PLC數(shù)據(jù)的監(jiān)聽，數(shù)據(jù)會傳輸?shù)紺ANoe里面。如圖中實物系統(tǒng)，Vector采用在不破壞相應真實充電槍線纜的情況下，通過耦合的方式直接從充電槍抓取相應的數(shù)據(jù)。在解密方面，維克多在工具里面提供多種方式，實現(xiàn)相應的數(shù)據(jù)解密。當然具體的解密需要依賴于實際的環(huán)境和拿到的信息，到底在工具層面，在CANoe里面如何實現(xiàn)相關(guān)的解密處理。當然對于這邊提供的這四種方式進行TLS的通訊解密，當然也適用于剛才提到的DoIP和SOME/IP等，在CANoe里面都可以實現(xiàn)。

車聯(lián)網(wǎng)-V2X的安全

車輛外互聯(lián)接口方面，尤其是在V2X這塊，在中國地區(qū)，我們看到很多的實驗區(qū)，包括三跨、四跨也在做相應的開發(fā)應用。在整個系統(tǒng)里面層面：在整個鏈路上，無論是車與車、車與其他設(shè)備進行通訊的時候，可以通過PC5實現(xiàn)V2X的數(shù)據(jù)傳輸，傳輸?shù)臄?shù)據(jù)上面會使用相應的證書進行的數(shù)據(jù)加密。以及相應數(shù)據(jù)進到車的內(nèi)部以后，車輛端的通信隨著OEM車內(nèi)安全技術(shù)的應用，對數(shù)據(jù)也進行相應的加密。

所以在車聯(lián)網(wǎng)V2X方面，在選擇工具的時候也有很多條件需要進行相應的考慮，當然很多供應商和OEM也不僅僅只會面臨中國的項目需要做，當然面對全球的項目都要做相應的支撐。在Security方面，中國的V2X安全規(guī)范目前還是Draft版本，但是對于歐美的安全規(guī)范ETSI TS 103 097和IEEE 1602.2都是發(fā)布狀態(tài)。在工具選擇方面，肯定是要能夠支持相應國家的Security。也需要支持各OEM車內(nèi)通信的安全加解密。另外工具需要支持常規(guī)車載通信開發(fā)和測試的要求，比如需要支持通信需要的arxml、診斷的cdd等，以及車載通信1000/100BASE-T1和CAN FD等連接通道。需要以長遠的視角規(guī)劃相應工具和設(shè)備，以實現(xiàn)V2X方面Security的處理。

在安全測試工具CANoe中提供Car2X的插件CANoe Option Car2X模塊。其中提供2D場景設(shè)計功能實現(xiàn)功能測試需要的測試場景，配置和產(chǎn)生V2X數(shù)據(jù)庫滿足在開發(fā)測試階段所需要的密鑰，包括密鑰的導入、生成，以及相應證書的管理和有效期配置等功能，面向安全通信在做證書和安全方面的測試，也得到了有效的支撐。

在針對中國安全標準方面，雖然當前國家規(guī)范還沒發(fā)布，但是CANoe Option Car2X在工具里面已經(jīng)有封裝中國Draft版本規(guī)范。可以通過工具看到在加密異常通信時，可以在分析窗口看到通信的實時數(shù)據(jù)采用紫色高亮顯示。CANoe Option Car2X里面也提供了一系列的API函數(shù)，方便做安全方面的測試驗證工作。 

安全互聯(lián)Connectivity

越來越多的OEM會使得車輛跟云端和后臺有相應的交互，以及隨著SOA的引進，整個系統(tǒng)不僅僅是車，也可能是車+后臺、車+運后、手機等等在內(nèi)的通訊應用。在車輛互聯(lián)方面主要的通訊技術(shù)：MQTT和HTTP。跟外部互聯(lián)通訊的時候都需要對相當?shù)臄?shù)據(jù)進行相應的加密和處理。在這種應用的情況下，也需要諸如CANoe等工具能夠支持MQTT或HTTP等協(xié)議。

這可能會有兩種情況需要考慮，一種情況是會接真實的ECU，ECU的一端是車內(nèi)常規(guī)通信，本身CANoe是擅長和支持的；ECU另一端的通信需要通過MQTT或HTTP實現(xiàn)和云端后臺的交互，當然在CANoe也可以通過相應的開發(fā)，直接使用MQTT和HTTP跟車外實現(xiàn)相應的通訊應用。

還有一種應用場景在開發(fā)早期的時候，必須跟云端應用交互的情況下，完全可以把整個軟件系統(tǒng)的的功能部署在虛擬環(huán)境里面，在虛擬環(huán)境里面的時候，直接訪問的是軟件接口，對軟件接口的訪問，相對于真實控制器的接口可以直接以更方便的方式實現(xiàn)，能夠在自己的PC和對應的環(huán)境下搭建虛擬環(huán)境實現(xiàn)MQTT和HTTP相應協(xié)議的互聯(lián)。車端或云端的軟件系統(tǒng)，均可使用CANoe或CANoe4SW實現(xiàn)互聯(lián)測試。

拿一個真實的例子來看，這邊有一個SUT，可以通過CANoe或CANoe4SW實現(xiàn)在虛擬環(huán)境的的測試，數(shù)據(jù)在傳輸中基于MQTT實現(xiàn)，把相應的數(shù)據(jù)傳到MQTT的Broker端，然后再通過Broker端把相應的數(shù)據(jù)傳到測試工具里面進行相應的處理。

在整個系統(tǒng)里面，就會遇到跟安全相關(guān)的，是會有證書部分，因為整個數(shù)據(jù)在通訊的時候要實現(xiàn)相應的安全通訊應用，這里面就會有不同的證書需要做相應的配置。比如在證書方面有PM格式或者PFX格式的證書，這個證書會產(chǎn)生CANoe所需要的證書，以及匹配SUT的證書，使得整個通訊鏈路本身也能夠?qū)崿F(xiàn)相應的加密通訊應用在里面。

另外在針對MQTT進行互聯(lián)通信服務時，不同開發(fā)階段需要的測試環(huán)境是有所差異的。在MQTT進行相應數(shù)據(jù)處理時，需要鏈接相應的MQTT Booker，在CANoe工具層面，可以支持云端后臺的Broker橋接，也可在局域網(wǎng)搭建，也支持在CANoe內(nèi)建立Booker。在CANoe內(nèi)部直接建立MQTT Booker這種應用，可以非常方便實現(xiàn)，故障注入和時間方面的測試應用。當然MQTT整個通訊的層面，整個數(shù)據(jù)有可能通過Google Protocol Buffer協(xié)議或JSON實現(xiàn)MQTT數(shù)據(jù)的虛擬化和反序列傳輸應用。無論是那種方式，在CANoe里面目前都是可以支持的。 

但是也看到在實際應用中，有一些應用去訪問云端、訪問后臺是比較受限的，這個時候的開發(fā)和測試對應的在CANoe層面提供一種比較實惠的方案給用戶參考。CANoe搭配IoT賦能硬件：VH4110，在這個硬件上面利用它本身的一些功能擴展諸多互聯(lián)協(xié)議，比如低功BLE、BT、LoRaWAN和ZigBee等相應協(xié)議，使得在測控制器本身功能的時候，所需要的外部互聯(lián)信號，可直接使用CANoe控制VH4110發(fā)給ECU，它們之間的交互在網(wǎng)絡(luò)和后臺無法訪問的時候，也是經(jīng)濟和實惠，比較方便的處理手段。

返回第一電動網(wǎng)首頁 >