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

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

帶有TLS的DoIP

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

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

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

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

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

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

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

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

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

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

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

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

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

安全互聯(lián)Connectivity

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

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

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

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

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

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

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