自主可信網(wǎng)聯(lián)汽車充電樁系統(tǒng)*

霍奕戎，范克科，歐 嵬

（1.中國(guó)人民大學(xué)附屬中學(xué)，北京 100080；2.海南大學(xué)，海南 ?？?570228）

0 引 言

近幾年，我國(guó)新能源汽車產(chǎn)業(yè)相關(guān)政策不斷出臺(tái)，2020 年10 月20 日，國(guó)務(wù)院印發(fā)《新能源汽車產(chǎn)業(yè)發(fā)展規(guī)劃（2021—2035 年）》，指出發(fā)展新能源汽車是我國(guó)從汽車大國(guó)邁向汽車強(qiáng)國(guó)的必由之路，是應(yīng)對(duì)氣候變化、推動(dòng)綠色發(fā)展的戰(zhàn)略舉措；2022 年1 月10 日，國(guó)家發(fā)展改革委、國(guó)家能源局等多部門聯(lián)合印發(fā)《國(guó)家發(fā)展改革委等部門關(guān)于進(jìn)一步提升電動(dòng)汽車充電基礎(chǔ)設(shè)施服務(wù)保障能力的實(shí)施意見(jiàn)》[1]。習(xí)近平總書(shū)記多次強(qiáng)調(diào)：“發(fā)展新能源汽車是我國(guó)邁向汽車強(qiáng)國(guó)的必由之路?！蓖苿?dòng)汽車從單純的交通工具向移動(dòng)智能終端、儲(chǔ)能單元和數(shù)字空間轉(zhuǎn)變，帶動(dòng)能源、交通、信息通信基礎(chǔ)設(shè)施改造升級(jí)，促進(jìn)能源消費(fèi)結(jié)構(gòu)優(yōu)化、交通體系和城市運(yùn)行智能化水平提升，對(duì)建設(shè)清潔美麗世界、構(gòu)建人類命運(yùn)共同體具有重要意義。

“十三五”期間，我國(guó)充電基礎(chǔ)設(shè)施實(shí)現(xiàn)了跨越式發(fā)展，充電技術(shù)快速提升，標(biāo)準(zhǔn)體系逐步完備，產(chǎn)業(yè)生態(tài)穩(wěn)步形成，建成世界上數(shù)量最多、輻射面積最大、服務(wù)車輛最全的充電基礎(chǔ)設(shè)施體系。截至2022 年1 月，全國(guó)總計(jì)上報(bào)公共類充電樁117.8 萬(wàn)臺(tái)，環(huán)比增加3.1 萬(wàn)臺(tái)，1 月保有量同比增長(zhǎng)45.2%。但就目前而言，充電樁產(chǎn)業(yè)快速發(fā)展的背后仍存在居住社區(qū)建樁難、公共充電設(shè)施發(fā)展不均衡、用戶充電體驗(yàn)有待提升、行業(yè)質(zhì)量與安全監(jiān)管體系有待完善等突出問(wèn)題[2]，亟須加快相關(guān)技術(shù)、模式與機(jī)制創(chuàng)新，進(jìn)一步提升充電服務(wù)保障能力。

首先，當(dāng)前電動(dòng)汽車配套服務(wù)系統(tǒng)智能化水平不高，運(yùn)營(yíng)方式的局限性和充換電車輛服務(wù)需求不斷增長(zhǎng)的矛盾越來(lái)越凸顯；其次，目前的充電樁服務(wù)系統(tǒng)側(cè)重于滿足用戶需求，對(duì)充電樁的遠(yuǎn)程監(jiān)控、使用者的身份驗(yàn)證以及用戶隱私信息保護(hù)缺乏安全考量[3]；最后，充電樁廠商的關(guān)注點(diǎn)更多集中于硬件安全，例如鋰電池合規(guī)性、充電樁過(guò)充等方面，忽略了新能源汽車智能化進(jìn)程中凸顯出的云端漏洞[4-7]。這些導(dǎo)致充電樁及其配套服務(wù)云平臺(tái)[8]漏洞頻出，安全攻擊層出不窮[9-10]：

（1）2018 年，施耐德電氣有限公司發(fā)布安全公告，該公司旗下電動(dòng)汽車充電樁產(chǎn)品EVLink Parking 被曝出多個(gè)安全漏洞：硬編碼憑證漏洞CVE-2018-7800、代碼注入漏洞CVE-2018-7801 以及結(jié)構(gòu)化查詢語(yǔ)言（Structured Query Language，SQL）漏洞CVE-2018-7802。攻擊者可通過(guò)以上漏洞運(yùn)用非法手段獲取系統(tǒng)或者設(shè)備的非法訪問(wèn)權(quán)限，對(duì)系統(tǒng)正常用戶及其云端系統(tǒng)具有極大的危害性。

（2）2020 年，GeekPwn2020 國(guó)際安全極客大賽中，騰訊的Blade Team 團(tuán)隊(duì)在比賽現(xiàn)場(chǎng)實(shí)現(xiàn)了對(duì)“無(wú)感支付”式直流式充電樁的漏洞攻擊演示：僅需要獲得模擬受害者的車輛身份標(biāo)識(shí)，并使用特殊設(shè)備，利用電動(dòng)汽車電池管理系統(tǒng)（Battery Management System，BMS）與直流充電樁通信協(xié)議中的身份認(rèn)證漏洞，就能輕松完成盜刷操作。

（3）充電樁運(yùn)營(yíng)平臺(tái)在整個(gè)充電流程中涉及充電樁啟停管控以及包括用戶金融賬戶、身份信息在內(nèi)的敏感隱私信息，而大多數(shù)充電樁運(yùn)營(yíng)平臺(tái)對(duì)充電樁沒(méi)有設(shè)置用戶訪問(wèn)控制策略，邊界防護(hù)措施薄弱，安全配置策略缺失，且運(yùn)維平臺(tái)一般暴露在公網(wǎng)中，受攻擊的可能性較大，極易造成用戶敏感信息的泄露；設(shè)備管理方面，在充電基礎(chǔ)設(shè)施進(jìn)行啟動(dòng)登錄、移動(dòng)終端登錄、運(yùn)營(yíng)平臺(tái)訪問(wèn)等過(guò)程中未使用身份認(rèn)證管理或在登錄過(guò)程中使用弱口令，容易造成信息泄露或篡改，甚至不可估量的損失。

針對(duì)上述問(wèn)題，基于我國(guó)充電樁產(chǎn)業(yè)信息安全現(xiàn)狀[11-19]，設(shè)計(jì)實(shí)現(xiàn)自主可信網(wǎng)聯(lián)汽車充電樁系統(tǒng)，致力提升用戶充電體驗(yàn)、完善充電樁安全監(jiān)管體系、助力信息基礎(chǔ)設(shè)施建設(shè)。

本文貢獻(xiàn)包括：

（1）通過(guò)商用密碼算法及其應(yīng)用體系，對(duì)用戶信息、充電樁信息和超文本傳輸協(xié)議（Hyper Text Transfer Protocol，HTTP）請(qǐng)求報(bào)文等數(shù)據(jù)進(jìn)行加密，使用SM2+SM3 對(duì)數(shù)據(jù)進(jìn)行數(shù)字簽名，保障數(shù)據(jù)的機(jī)密性與完整性[20-21]；在散列消息身份驗(yàn)證碼（Hashed Message Authentication Code，HMAC）密鑰交換過(guò)程中使用臨時(shí)交互號(hào)N 與標(biāo)識(shí)符ID 來(lái)驗(yàn)證雙方的身份，抵御中間人攻擊。

（2）利用聯(lián)盟鏈技術(shù)不可篡改、去中心化、可追溯等特點(diǎn)，進(jìn)行鏈上密鑰分配與管理。在鏈上密鑰分配時(shí)，使用基于SM3 的HMAC 算法，確保只有擁有HMAC 密鑰且通過(guò)區(qū)塊鏈CA 認(rèn)證的實(shí)體才能獲取密鑰，保障密鑰的唯一性與可認(rèn)證性。

（3）建立新的網(wǎng)絡(luò)安全邊界[22]，實(shí)現(xiàn)訪問(wèn)實(shí)體的強(qiáng)身份認(rèn)證；在邊界防護(hù)、通信傳輸、身份鑒別、數(shù)據(jù)保密等方面，進(jìn)一步收窄系統(tǒng)暴露面，更細(xì)粒度地保障業(yè)務(wù)系統(tǒng)安全[23]。

本文首先描述了方案的整體架構(gòu)、闡述了主要功能模塊；其次通過(guò)實(shí)驗(yàn)驗(yàn)證了所提方案的Web 應(yīng)用、區(qū)塊鏈系統(tǒng)的性能；最后總結(jié)全文，并提出了未來(lái)工作展望。

1 網(wǎng)聯(lián)汽車充電樁方案設(shè)計(jì)

1.1 整體架構(gòu)

如圖1 所示，網(wǎng)聯(lián)汽車充電樁系統(tǒng)包括訪問(wèn)實(shí)體、安全網(wǎng)關(guān)、云平臺(tái)應(yīng)用服務(wù)、策略控制中心、云平臺(tái)安全防護(hù)體系支撐組件5 大模塊。

圖1 整體架構(gòu)

1.1.1 訪問(wèn)實(shí)體

根據(jù)所處網(wǎng)絡(luò)域環(huán)境，將訪問(wèn)實(shí)體劃分為云平臺(tái)外網(wǎng)實(shí)體和云平臺(tái)內(nèi)網(wǎng)實(shí)體。云平臺(tái)外網(wǎng)實(shí)體包括已投入使用的充電樁設(shè)備、使用相關(guān)服務(wù)的普通用戶和維修人員等實(shí)體。云平臺(tái)內(nèi)網(wǎng)實(shí)體則包括軟件和硬件開(kāi)發(fā)人員、服務(wù)運(yùn)維人員和測(cè)試人員等。

1.1.2 安全網(wǎng)關(guān)

安全網(wǎng)關(guān)作為實(shí)體訪問(wèn)云平臺(tái)的唯一入口，負(fù)責(zé)對(duì)訪問(wèn)實(shí)體進(jìn)行身份識(shí)別與訪問(wèn)控制，網(wǎng)關(guān)能夠?qū)⒃L問(wèn)實(shí)體與平臺(tái)資源隔離開(kāi)來(lái)，使云平臺(tái)應(yīng)用服務(wù)隱藏于零信任網(wǎng)關(guān)之后，大大減少攻擊面[24-25]。同時(shí)，采用先認(rèn)證后訪問(wèn)的方式，只有當(dāng)訪問(wèn)實(shí)體被認(rèn)證為合法身份后，才能訪問(wèn)云平臺(tái)的應(yīng)用服務(wù)。此外，根據(jù)策略控制中心返回的評(píng)估結(jié)果，對(duì)訪問(wèn)實(shí)體進(jìn)行訪問(wèn)管理。網(wǎng)關(guān)與訪問(wèn)實(shí)體和云平臺(tái)之間的通信使用商用密碼安全套接字協(xié)議（Secure Sockets Layer，SSL）保護(hù)，并通過(guò)SM2、SM3、SM4 保障數(shù)據(jù)的完整性、可追溯性以及抗抵賴性。

1.1.3 云平臺(tái)應(yīng)用服務(wù)

云平臺(tái)應(yīng)用服務(wù)由云平臺(tái)的各項(xiàng)應(yīng)用服務(wù)封裝而成，分為公開(kāi)服務(wù)和內(nèi)網(wǎng)服務(wù)。其中，公開(kāi)服務(wù)面向所有實(shí)體開(kāi)放，具有良好的耦合度，負(fù)責(zé)對(duì)通過(guò)零信任安全網(wǎng)關(guān)的合法流量請(qǐng)求進(jìn)行響應(yīng)，提供相應(yīng)服務(wù)；內(nèi)網(wǎng)服務(wù)則只對(duì)通過(guò)強(qiáng)身份認(rèn)證的內(nèi)網(wǎng)域環(huán)境實(shí)體開(kāi)放，外網(wǎng)域環(huán)境實(shí)體或未通過(guò)身份認(rèn)證的內(nèi)網(wǎng)域環(huán)境實(shí)體將無(wú)法訪問(wèn)相關(guān)資源[26-28]。

1.1.4 策略控制中心

該模塊接收由安全網(wǎng)關(guān)所記錄的實(shí)體訪問(wèn)行為事件，并將行為事件上鏈[29]，保障行為事件的不可篡改性與可追溯性。同時(shí)，決策引擎將根據(jù)行為事件和預(yù)設(shè)安全策略配置對(duì)訪問(wèn)實(shí)體進(jìn)行持續(xù)驗(yàn)證、評(píng)估與分析，提供場(chǎng)景和風(fēng)險(xiǎn)感知的動(dòng)態(tài)授權(quán)。

1.1.5 云平臺(tái)安全防護(hù)體系支撐組件

云平臺(tái)安全防護(hù)體系支撐組件主要由密碼基礎(chǔ)設(shè)施、區(qū)塊鏈管理、日志審計(jì)和權(quán)限管理4 個(gè)子模塊組成，負(fù)責(zé)終端設(shè)備與訪問(wèn)實(shí)體的證書(shū)簽發(fā)服務(wù)和區(qū)塊鏈網(wǎng)絡(luò)的管理，實(shí)現(xiàn)了對(duì)網(wǎng)絡(luò)出入站流量與服務(wù)端設(shè)備運(yùn)行環(huán)境和運(yùn)行狀態(tài)的實(shí)時(shí)監(jiān)控[18,30]。同時(shí)，根據(jù)最小權(quán)限原則，將完整權(quán)限進(jìn)行細(xì)粒度分級(jí)，根據(jù)訪問(wèn)實(shí)體的身份信息和可信任程度來(lái)管控其權(quán)限等級(jí)，實(shí)現(xiàn)安全高效的權(quán)限控制機(jī)制[31]。

1.2 主要功能模塊

1.2.1 強(qiáng)身份認(rèn)證

云平臺(tái)基于B/S 架構(gòu)，通過(guò)嚴(yán)格的身份認(rèn)證保障系統(tǒng)的安全性與操作的合法性[32]。身份認(rèn)證模塊由前后端不同的處理邏輯實(shí)現(xiàn)。

后端的身份認(rèn)證主要基于挑戰(zhàn)/響應(yīng)的雙向認(rèn)證機(jī)制和公鑰證書(shū)，實(shí)現(xiàn)對(duì)終端與平臺(tái)的強(qiáng)身份認(rèn)證。挑戰(zhàn)/響應(yīng)認(rèn)證機(jī)制是一系列協(xié)議的統(tǒng)稱，在該系列協(xié)議中，其中一方提出問(wèn)題（挑戰(zhàn)），另一方提供有效的答案并進(jìn)行身份驗(yàn)證（響應(yīng)），只有答案有效才能通過(guò)驗(yàn)證[33]，詳細(xì)認(rèn)證流程如圖2 所示。

圖2 雙向認(rèn)證流程

挑戰(zhàn)/響應(yīng)的雙向認(rèn)證具體步驟如下：首先，終端嘗試連接至云平臺(tái)，身份認(rèn)證開(kāi)始。終端生成一個(gè)隨機(jī)數(shù)R1作為響應(yīng)值，并將終端證書(shū)和R1發(fā)送到云平臺(tái)的網(wǎng)關(guān)。然后，網(wǎng)關(guān)驗(yàn)證接收到的證書(shū)，并使用SM2 和網(wǎng)關(guān)私鑰對(duì)R1進(jìn)行簽名，得到簽名值Sig1，并將其證書(shū)和Sig1發(fā)送到終端。當(dāng)終端接收到網(wǎng)關(guān)證書(shū)后，對(duì)其進(jìn)行驗(yàn)證。如果證書(shū)有效，終端將根據(jù)證書(shū)上攜帶的網(wǎng)關(guān)公鑰來(lái)驗(yàn)證Sig1；否則，終端對(duì)云平臺(tái)的身份認(rèn)證失敗，通信終止。當(dāng)上述過(guò)程結(jié)束時(shí)，網(wǎng)關(guān)生成一個(gè)隨機(jī)數(shù)R2作為響應(yīng)值，并將其發(fā)送給終端。接下來(lái)，終端用其私鑰對(duì)R2進(jìn)行簽名，并將簽名發(fā)送到網(wǎng)關(guān)。最后，網(wǎng)關(guān)根據(jù)終端的證書(shū)驗(yàn)證Sig2。如果Sig2有效，則成功建立連接。否則，連接建立失敗，通信終止。上述過(guò)程結(jié)束則身份驗(yàn)證過(guò)程完成。

后端還采用基于JSON Web Token（JWT）的訪問(wèn)控制和Spring Security 權(quán)限控制，Token 令牌隨用戶登錄而自動(dòng)獲取。此外，根據(jù)管理員賬戶與普通用戶賬戶的職能和需求的不同，通過(guò)Spring Security 來(lái)控制這兩類賬戶的不同權(quán)限，只有管理員可以進(jìn)行遠(yuǎn)程控制等操作，普通用戶只能查看訂單相關(guān)信息和訪問(wèn)狀態(tài)監(jiān)控模塊，以保證云平臺(tái)的安全性。權(quán)限控制原理如圖3 所示。

圖3 普通用戶權(quán)限控制

1.2.2 數(shù)據(jù)管理

數(shù)據(jù)管理模塊包括鏈上數(shù)據(jù)管理、數(shù)據(jù)端對(duì)端交互、數(shù)據(jù)持久化存儲(chǔ)。

（1）鏈上數(shù)據(jù)管理。本系統(tǒng)中，區(qū)塊鏈用于對(duì)稱密鑰管理與動(dòng)態(tài)評(píng)估事件的存儲(chǔ)，主要分為鏈上密鑰管理和鏈上事件管理。

①鏈上密鑰管理。采用Fabric 聯(lián)盟鏈進(jìn)行云平臺(tái)與充電樁之間的密鑰管理，主要包括密鑰的臨時(shí)存儲(chǔ)與分發(fā)[34]。首先，在云平臺(tái)本地環(huán)境上搭建并運(yùn)行Fabric 網(wǎng)絡(luò)主環(huán)境，將云平臺(tái)作為擁有最高權(quán)限的管理員節(jié)點(diǎn)，本文所搭建的測(cè)試網(wǎng)絡(luò)配置為2 個(gè)組織、1 個(gè)order 節(jié)點(diǎn)、4 個(gè)peer 節(jié)點(diǎn)與1 個(gè)CA 節(jié)點(diǎn)。首先，在充電樁上配置Fabric 基本服務(wù)，將充電樁作為擁有一般權(quán)限的普通節(jié)點(diǎn)加入云平臺(tái)所搭建的區(qū)塊鏈網(wǎng)絡(luò)中，共同維護(hù)Fabric 網(wǎng)絡(luò)的分布式賬本；其次，云平臺(tái)生成一對(duì)SM2 公鑰和私鑰，并將所生成的私鑰物理寫(xiě)入充電樁的存儲(chǔ)設(shè)備中，該方式中的私鑰未參與通信，只有讀取云平臺(tái)與充電樁的存儲(chǔ)設(shè)備才能獲得私鑰，一般情況下不存在泄露風(fēng)險(xiǎn)，從而起到安全地事先共享一對(duì)公私鑰的作用；最后，充電樁需要與云平臺(tái)進(jìn)行密鑰交換，該交換基于SM2 非對(duì)稱加密，所交換的密鑰為HMAC 所用密鑰[35]。HMAC 密鑰由云平臺(tái)生成，通過(guò)臨時(shí)交互號(hào)N與身份標(biāo)識(shí)符ID來(lái)進(jìn)行身份認(rèn)證與防止重放攻擊，能有效抵御中間人攻擊，保證密鑰的可認(rèn)證性與保密性。其中，臨時(shí)交互號(hào)N為采用真實(shí)物理環(huán)境中的隨機(jī)事件作為種子所生成的強(qiáng)隨機(jī)數(shù)，身份標(biāo)識(shí)符ID由通用唯一識(shí)別碼（Universally Unique Identifier，UUID）、序列號(hào)生成，交換流程如圖4 所示。

圖4 HMAC 密鑰交換

②鏈上事件管理。采用聯(lián)盟鏈存儲(chǔ)評(píng)估事件，并使用不同于密鑰管理的區(qū)塊鏈網(wǎng)絡(luò)組織進(jìn)行管理，如圖5 所示。每個(gè)節(jié)點(diǎn)持有一份數(shù)據(jù)賬本，事件的不可篡改性由所有節(jié)點(diǎn)共同背書(shū)，保障事件的安全可信存儲(chǔ)。由于在聯(lián)盟鏈中，不同組織之間的數(shù)據(jù)不主動(dòng)相通，從而實(shí)現(xiàn)密鑰數(shù)據(jù)與事件數(shù)據(jù)的隔離存儲(chǔ)，保障密鑰數(shù)據(jù)與事件數(shù)據(jù)之間的獨(dú)立性，避免數(shù)據(jù)管理混亂。

圖5 區(qū)塊鏈測(cè)試網(wǎng)絡(luò)結(jié)構(gòu)

（2）數(shù)據(jù)端對(duì)端交互。為了保證端對(duì)端之間的數(shù)據(jù)通信的機(jī)密性、完整性與可認(rèn)證性，對(duì)參與通信的數(shù)據(jù)采用SM2、SM4 加密，利用SM2、SM3進(jìn)行數(shù)字簽名，數(shù)據(jù)塊處理如圖6所示。

數(shù)據(jù)發(fā)送端使用SM2對(duì)原始數(shù)據(jù)進(jìn)行簽名，并通過(guò)SM4對(duì)整個(gè)數(shù)據(jù)和簽名進(jìn)行加密后發(fā)送，接收端解密后使用公鑰進(jìn)行驗(yàn)簽，成功則通信完成，否則返回異常報(bào)告。該方法有效保障了用戶隱私安全與關(guān)鍵數(shù)據(jù)安全，處理流程如圖7所示。

圖7 前后端數(shù)據(jù)傳輸流程

由于充電樁本身的特殊性，重放攻擊能夠造成的危害極大，甚至能反復(fù)控制充電樁的通電、斷電，損壞電動(dòng)汽車電池，影響電網(wǎng)運(yùn)行的穩(wěn)定，對(duì)充電樁、電動(dòng)汽車、電網(wǎng)設(shè)施的信息安全與物理安全造成嚴(yán)重威脅。因此，本文采用“時(shí)間戳+隨機(jī)數(shù)”的方法來(lái)有效防止重復(fù)攻擊。該方法在每一條HTTP 請(qǐng)求上增加了“timeStampCode”字段，該字段由時(shí)間戳與隨機(jī)數(shù)拼接而成，時(shí)間戳根據(jù)當(dāng)前生成時(shí)間與1970 年1 月1 日之間的時(shí)間差計(jì)算而成，精確至毫秒級(jí)別，能顯著提高被成功猜測(cè)與碰撞的難度。隨機(jī)數(shù)則使用強(qiáng)隨機(jī)數(shù)，采用算法SHA1PRNG 生成，以CPU 的熱噪聲、磁盤(pán)讀寫(xiě)的字節(jié)、鍵盤(pán)的敲擊等現(xiàn)實(shí)環(huán)境中的隨機(jī)事件產(chǎn)生的熵作為種子，具有密碼學(xué)安全。校驗(yàn)流程如圖8 所示。

圖8 校驗(yàn)流程

（3）數(shù)據(jù)持久化存儲(chǔ)。當(dāng)請(qǐng)求校驗(yàn)成功后，開(kāi)始執(zhí)行請(qǐng)求內(nèi)容，若請(qǐng)求中攜帶數(shù)據(jù)，則使用對(duì)稱密鑰對(duì)密文進(jìn)行解密，使用相應(yīng)公鑰對(duì)數(shù)字簽名進(jìn)行驗(yàn)簽，若驗(yàn)簽成功，則數(shù)據(jù)未遭攻擊，使用MySQL 數(shù)據(jù)庫(kù)進(jìn)行持久化存儲(chǔ)。若驗(yàn)簽失敗，則數(shù)據(jù)完整性遭到破壞，廢棄請(qǐng)求，拒絕訪問(wèn)。處理流程如圖9 所示。

圖9 請(qǐng)求數(shù)據(jù)簽名驗(yàn)證

1.2.3 狀態(tài)監(jiān)控

（1）云平臺(tái)服務(wù)監(jiān)控。云平臺(tái)服務(wù)監(jiān)控基于Spring Boot 構(gòu)建，使用Drools 規(guī)則引擎管理風(fēng)控規(guī)則，其特點(diǎn)是配置簡(jiǎn)單并支持動(dòng)態(tài)調(diào)整規(guī)則，是一套分析平臺(tái)風(fēng)險(xiǎn)事件、動(dòng)態(tài)調(diào)整風(fēng)控規(guī)則、自動(dòng)精準(zhǔn)預(yù)警風(fēng)險(xiǎn)、保障平臺(tái)安全運(yùn)行的系統(tǒng)。服務(wù)監(jiān)控模塊的工作流程如圖10 所示。

圖10 服務(wù)監(jiān)控流程

（2）充電樁服務(wù)監(jiān)控。通過(guò)設(shè)置定時(shí)任務(wù)，使得充電樁在每個(gè)固定的時(shí)間間隔通過(guò)HTTP 請(qǐng)求向云平臺(tái)持續(xù)匯報(bào)狀態(tài)信息，包括硬件溫度、充電樁所處狀態(tài)（通電、斷電、鎖定）、累計(jì)充電量等數(shù)據(jù)，服務(wù)信息經(jīng)過(guò)SM4 加密與SM2簽名，并附加了時(shí)間戳+隨機(jī)數(shù)，能有效保障信息的完整性與真實(shí)性，防止其受到中間人攻擊與重放攻擊。

（3）遠(yuǎn)程控制。由于充電樁部署在公開(kāi)環(huán)境中，因此在實(shí)際場(chǎng)景中，充電樁的運(yùn)行環(huán)境復(fù)雜多樣，難免會(huì)遭遇某些特殊情況，如人為損壞、自然災(zāi)害、安全漏洞等，從而需要通過(guò)臨時(shí)改變充電樁的運(yùn)行狀態(tài)來(lái)防止安全事故、財(cái)產(chǎn)損失，保護(hù)充電樁安全，基于此，亟需一種便捷高效的手段來(lái)實(shí)現(xiàn)對(duì)充電樁運(yùn)行狀態(tài)的靈活控制[5]。因此，本系統(tǒng)設(shè)計(jì)了遠(yuǎn)程控制模塊，可以通過(guò)云平臺(tái)來(lái)遠(yuǎn)程控制充電樁的運(yùn)行狀態(tài)，根據(jù)序列號(hào)來(lái)選擇要進(jìn)行控制的充電樁，再根據(jù)指令cmd 來(lái)改變充電樁狀態(tài)，指令與充電樁的狀態(tài)相對(duì)應(yīng)，包括LOCK、ON、OFF、UNLOCK、SHUTDOWN、REBOOT，其中，LOCK 指令表示鎖定充電樁，拒絕除云平臺(tái)以外的其他所有實(shí)體的訪問(wèn)，不允許用戶繼續(xù)使用充電等功能，是擁有最高優(yōu)先級(jí)的指令；ON 指令表示開(kāi)啟充電樁充電功能，使充電樁進(jìn)入充電狀態(tài)，但當(dāng)充電樁處于LOCK 狀態(tài)時(shí)，該指令無(wú)效；OFF指令表示關(guān)閉充電樁充電功能，使充電樁停止充電；UNLOCK 指令表示解鎖充電樁，將充電樁從LOCK 狀態(tài)切換為OFF 狀態(tài)，重新允許其他實(shí)體的訪問(wèn)，充電樁再次進(jìn)入正常工作狀態(tài)；SHUTDOWN 指令表示徹底關(guān)閉充電樁系統(tǒng)，使充電樁進(jìn)入關(guān)機(jī)狀態(tài)；REBOOT 指令表示重啟充電樁，常用于充電樁系統(tǒng)更新中。遠(yuǎn)程控制流程如圖11 所示。

圖11 充電樁遠(yuǎn)程控制流程

2 系統(tǒng)測(cè)試

2.1 測(cè)試環(huán)境

測(cè)試軟件信息如表1 所示。測(cè)試服務(wù)器配置如表2 所示。客戶端配置如表3 所示。

表1 測(cè)試軟件信息

表2 服務(wù)器配置

表3 客戶端配置

2.2 Web 應(yīng)用性能

本實(shí)驗(yàn)的目的是檢驗(yàn)本文所設(shè)計(jì)實(shí)現(xiàn)的云平臺(tái)系統(tǒng)是否具有良好的性能，并考察在不同的用戶負(fù)載下，云平臺(tái)對(duì)用戶請(qǐng)求做出的響應(yīng)情況，以確保將來(lái)系統(tǒng)運(yùn)行的安全性、可靠性和執(zhí)行效率。

2.2.1 測(cè)試工具

采用LoadRunner 性能自動(dòng)化測(cè)試工具測(cè)試系統(tǒng)性能。通過(guò)創(chuàng)建虛擬用戶，在高并發(fā)量和模擬真實(shí)環(huán)境的背景下，實(shí)時(shí)監(jiān)控系統(tǒng)性能。

2.2.2 測(cè)試描述

對(duì)云平臺(tái)的功能進(jìn)行測(cè)試。檢驗(yàn)云平臺(tái)功能的可用性與穩(wěn)定性，在高并發(fā)、高負(fù)載的環(huán)境下測(cè)試Web 應(yīng)用的性能，觀察并統(tǒng)計(jì)吞吐量、CPU 使用率、內(nèi)存占用率等指標(biāo)。本次測(cè)試的要求是驗(yàn)證在30 分鐘內(nèi)完成2 000 次用戶登錄系統(tǒng)，然后執(zhí)行開(kāi)始充電、停止充電等基本業(yè)務(wù)，最后退出。

2.2.3 性能指標(biāo)

各測(cè)試項(xiàng)目標(biāo)值如表4 所示。

表4 Web 性能指標(biāo)

（1）數(shù)據(jù)摘要。LoadRunner 進(jìn)行場(chǎng)景測(cè)試結(jié)果收集后，首先顯示該結(jié)果的一個(gè)摘要信息，如圖12所示。概要中列出了“Statistics Summary（統(tǒng)計(jì)信息摘要）”“Transaction Summary（交易摘要）”以及“HTTP Responses Summary（HTTP 請(qǐng)求響應(yīng)摘要）”等。以簡(jiǎn)要的信息列出本次測(cè)試結(jié)果。

圖12 性能測(cè)試結(jié)果摘要

（2）結(jié)果分析。獲得上述數(shù)據(jù)后，最新的測(cè)試結(jié)果記錄如表5 所示。

表5 Web 測(cè)試結(jié)果

本次測(cè)試運(yùn)行的最大并發(fā)數(shù)為237，總吞吐量為842 037 409 字節(jié)，平均每秒的吞吐量為451 979 字節(jié)，總的請(qǐng)求數(shù)為211 974，平均每秒的請(qǐng)求為113.781。從上述結(jié)果可知，本文所設(shè)計(jì)實(shí)現(xiàn)的云平臺(tái)性能良好，滿足預(yù)設(shè)性能指標(biāo)基準(zhǔn)，證明了該系統(tǒng)能夠承載日常的并發(fā)數(shù)和并發(fā)量，并在一定程度的并發(fā)與負(fù)載壓力下，仍能保障系統(tǒng)運(yùn)行的穩(wěn)定性和可用性。

2.3 區(qū)塊鏈系統(tǒng)性能

2.3.1 測(cè)試工具

Hyperledger Caliper 是一個(gè)開(kāi)源的通用區(qū)塊鏈性能測(cè)試工具。Hyperledger 項(xiàng)目下設(shè)了性能及可擴(kuò)展性工作組，負(fù)責(zé)對(duì)各種性能指標(biāo)（TPS、延遲、資源利用率等）進(jìn)行形式化、規(guī)范化的定義，Caliper 在設(shè)計(jì)時(shí)也采用了這一套性能指標(biāo)體系并內(nèi)嵌進(jìn)框架中。Caliper 能夠方便地對(duì)接多種區(qū)塊鏈平臺(tái)并屏蔽了底層細(xì)節(jié)，用戶只需要負(fù)責(zé)設(shè)計(jì)具體的測(cè)試流程，即可獲取Caliper輸出的可視化性能測(cè)試報(bào)告?？梢?jiàn)擁有這些特點(diǎn)的Caliper，能恰好滿足項(xiàng)目中區(qū)塊鏈部分對(duì)壓測(cè)工具的需求。

2.3.2 測(cè)試標(biāo)準(zhǔn)

采用的區(qū)塊鏈標(biāo)準(zhǔn)以《可信區(qū)塊鏈第1 部分：區(qū)塊鏈技術(shù)參考架構(gòu)》《可信區(qū)塊鏈第2 部分：總體要求和評(píng)價(jià)指標(biāo)》《可信區(qū)塊鏈第3 部分：測(cè)評(píng)方法》作為參考，其中區(qū)塊鏈行業(yè)標(biāo)準(zhǔn)如表6 所示。

表6 區(qū)塊鏈行業(yè)標(biāo)準(zhǔn)

2.3.3 測(cè)試描述

為驗(yàn)證鏈上數(shù)據(jù)管理模塊的穩(wěn)定性與可用性，本測(cè)試在高并發(fā)、高負(fù)載的環(huán)境下，分別以執(zhí)行數(shù)據(jù)上鏈功能（數(shù)據(jù)存儲(chǔ)）的invoke 合約與執(zhí)行鏈上查詢功能（數(shù)據(jù)獲?。┑膓uery 合約作為測(cè)試對(duì)象，通過(guò)Caliper 實(shí)時(shí)監(jiān)控測(cè)試過(guò)程中區(qū)塊鏈系統(tǒng)的每秒交易接收量以及每秒交易上鏈量，控制發(fā)送的壓力，維持兩者數(shù)值始終大體一致，使得壓力剛剛達(dá)到系統(tǒng)的瓶頸。對(duì)于尖峰沖擊，則通過(guò)增加發(fā)送的壓力，讓系統(tǒng)每秒交易接收量達(dá)到每秒上鏈量的兩倍，使得壓力遠(yuǎn)遠(yuǎn)超過(guò)系統(tǒng)的瓶頸上限，觀察系統(tǒng)在極端情況下的運(yùn)轉(zhuǎn)情況。測(cè)試方案如表7 所示。

表7 區(qū)塊鏈測(cè)試方案

（1）數(shù)據(jù)摘要。invoke 合約與query 合約的測(cè)試結(jié)果分別如圖13、圖14 所示。

圖13 invoke 合約測(cè)試結(jié)果

圖14 query 合約測(cè)試結(jié)果

將數(shù)據(jù)匯總整理后如表8 所示。

表8 測(cè)試數(shù)據(jù)

（2）結(jié)果分析。采用Caliper 對(duì)區(qū)塊鏈進(jìn)行性能測(cè)試，對(duì)交易延遲場(chǎng)景進(jìn)行了低負(fù)載測(cè)試，對(duì)系統(tǒng)吞吐量進(jìn)行了高負(fù)載測(cè)試，使得壓力達(dá)到系統(tǒng)的瓶頸，對(duì)尖峰沖擊場(chǎng)景進(jìn)行了超過(guò)瓶頸的2 倍流量沖擊測(cè)試。Caliper 自動(dòng)記錄下設(shè)定好的時(shí)間點(diǎn)的數(shù)據(jù)，最終生成測(cè)試結(jié)果。如表8 中的Caliper 測(cè)試結(jié)果報(bào)告所示，本次測(cè)試的交易成功率為100%，交易失敗率為0，對(duì)于invoke合約：發(fā)送速率為379 TPS，最大交易延遲為5.59 s，最小交易延遲為1.39 s，平均交易延遲為3.32 s，交易吞吐量為226 TPS；對(duì)于query 合約：發(fā)送速率為399 TPS，最大交易延遲為4.67 s，最小交易延遲為0.01 s，平均交易延遲為1.15 s，交易吞吐量為385 TPS。測(cè)試結(jié)果表明：本文所采用的區(qū)塊鏈方案具有良好的穩(wěn)定性，能夠滿足實(shí)際業(yè)務(wù)需求，確保鏈上數(shù)據(jù)管理功能的可用性，各項(xiàng)指標(biāo)測(cè)試均符合行業(yè)標(biāo)準(zhǔn)。

本節(jié)對(duì)前文所提解決方案進(jìn)行了具體實(shí)現(xiàn)，即云平臺(tái)系統(tǒng)與區(qū)塊鏈系統(tǒng)，并分別通過(guò)Web應(yīng)用性能測(cè)試與區(qū)塊鏈系統(tǒng)性能測(cè)試對(duì)所設(shè)計(jì)實(shí)現(xiàn)的云平臺(tái)系統(tǒng)與區(qū)塊鏈系統(tǒng)的性能進(jìn)行詳細(xì)測(cè)試。測(cè)試結(jié)果表明，通過(guò)本文方案所實(shí)現(xiàn)的云平臺(tái)系統(tǒng)與區(qū)塊鏈系統(tǒng)性能良好，各項(xiàng)指標(biāo)均符合所參考的測(cè)試性能基準(zhǔn)，在實(shí)驗(yàn)所設(shè)的高負(fù)載與高并發(fā)環(huán)境下，仍能保證系統(tǒng)功能的穩(wěn)定性和可用性，能夠滿足實(shí)際業(yè)務(wù)需求，符合預(yù)期目標(biāo)。

3 結(jié) 語(yǔ)

隨著電動(dòng)汽車充電設(shè)施的日益數(shù)字化和智能化，網(wǎng)聯(lián)汽車充電樁的信息安全已成為不容小覷的問(wèn)題。本文對(duì)網(wǎng)聯(lián)汽車充電樁與管理云平臺(tái)的安全開(kāi)展了重點(diǎn)研究，設(shè)計(jì)實(shí)現(xiàn)了基于商用密碼與區(qū)塊鏈的網(wǎng)聯(lián)汽車充電樁安全系統(tǒng)。可操作性方面，系統(tǒng)采用主流開(kāi)發(fā)框架與科學(xué)設(shè)計(jì)模式，通過(guò)B/S 架構(gòu)實(shí)現(xiàn)服務(wù)的解耦開(kāi)發(fā)、便捷維護(hù)、安全升級(jí)和穩(wěn)定訪問(wèn)，提升用戶使用體驗(yàn)；安全性方面，系統(tǒng)采用商用密碼算法SM2、SM3、SM4，基于國(guó)密版Fabric 聯(lián)盟鏈進(jìn)行鏈上密鑰管理，保證充電樁數(shù)據(jù)的全生命周期安全。

下一步工作：①優(yōu)化前端界面與組件樣式，提升用戶體驗(yàn)；②引入零信任技術(shù)，加強(qiáng)系統(tǒng)安全防護(hù)；③完善動(dòng)態(tài)信任評(píng)估，加強(qiáng)身份認(rèn)證策略。