霍奕戎,范克科,歐 嵬
(1.中國人民大學(xué)附屬中學(xué),北京 100080;2.海南大學(xué),海南 ???570228)
近幾年,我國新能源汽車產(chǎn)業(yè)相關(guān)政策不斷出臺(tái),2020 年10 月20 日,國務(wù)院印發(fā)《新能源汽車產(chǎn)業(yè)發(fā)展規(guī)劃(2021—2035 年)》,指出發(fā)展新能源汽車是我國從汽車大國邁向汽車強(qiáng)國的必由之路,是應(yīng)對(duì)氣候變化、推動(dòng)綠色發(fā)展的戰(zhàn)略舉措;2022 年1 月10 日,國家發(fā)展改革委、國家能源局等多部門聯(lián)合印發(fā)《國家發(fā)展改革委等部門關(guān)于進(jìn)一步提升電動(dòng)汽車充電基礎(chǔ)設(shè)施服務(wù)保障能力的實(shí)施意見》[1]。習(xí)近平總書記多次強(qiáng)調(diào):“發(fā)展新能源汽車是我國邁向汽車強(qiáng)國的必由之路?!蓖苿?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)共同體具有重要意義。
“十三五”期間,我國充電基礎(chǔ)設(shè)施實(shí)現(xiàn)了跨越式發(fā)展,充電技術(shù)快速提升,標(biāo)準(zhǔn)體系逐步完備,產(chǎn)業(yè)生態(tài)穩(wěn)步形成,建成世界上數(shù)量最多、輻射面積最大、服務(wù)車輛最全的充電基礎(chǔ)設(shè)施體系。截至2022 年1 月,全國總計(jì)上報(bào)公共類充電樁117.8 萬臺(tái),環(huán)比增加3.1 萬臺(tái),1 月保有量同比增長45.2%。但就目前而言,充電樁產(chǎn)業(yè)快速發(fā)展的背后仍存在居住社區(qū)建樁難、公共充電設(shè)施發(fā)展不均衡、用戶充電體驗(yàn)有待提升、行業(yè)質(zhì)量與安全監(jiān)管體系有待完善等突出問題[2],亟須加快相關(guān)技術(shù)、模式與機(jī)制創(chuàng)新,進(jìn)一步提升充電服務(wù)保障能力。
首先,當(dāng)前電動(dòng)汽車配套服務(wù)系統(tǒng)智能化水平不高,運(yùn)營方式的局限性和充換電車輛服務(wù)需求不斷增長的矛盾越來越凸顯;其次,目前的充電樁服務(wù)系統(tǒng)側(cè)重于滿足用戶需求,對(duì)充電樁的遠(yuǎn)程監(jiān)控、使用者的身份驗(yàn)證以及用戶隱私信息保護(hù)缺乏安全考量[3];最后,充電樁廠商的關(guān)注點(diǎn)更多集中于硬件安全,例如鋰電池合規(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)化查詢語言(Structured Query Language,SQL)漏洞CVE-2018-7802。攻擊者可通過以上漏洞運(yùn)用非法手段獲取系統(tǒng)或者設(shè)備的非法訪問權(quán)限,對(duì)系統(tǒng)正常用戶及其云端系統(tǒng)具有極大的危害性。
(2)2020 年,GeekPwn2020 國際安全極客大賽中,騰訊的Blade Team 團(tuán)隊(duì)在比賽現(xiàn)場實(shí)現(xiàn)了對(duì)“無感支付”式直流式充電樁的漏洞攻擊演示:僅需要獲得模擬受害者的車輛身份標(biāo)識(shí),并使用特殊設(shè)備,利用電動(dòng)汽車電池管理系統(tǒng)(Battery Management System,BMS)與直流充電樁通信協(xié)議中的身份認(rèn)證漏洞,就能輕松完成盜刷操作。
(3)充電樁運(yùn)營平臺(tái)在整個(gè)充電流程中涉及充電樁啟停管控以及包括用戶金融賬戶、身份信息在內(nèi)的敏感隱私信息,而大多數(shù)充電樁運(yùn)營平臺(tái)對(duì)充電樁沒有設(shè)置用戶訪問控制策略,邊界防護(hù)措施薄弱,安全配置策略缺失,且運(yùn)維平臺(tái)一般暴露在公網(wǎng)中,受攻擊的可能性較大,極易造成用戶敏感信息的泄露;設(shè)備管理方面,在充電基礎(chǔ)設(shè)施進(jìn)行啟動(dòng)登錄、移動(dòng)終端登錄、運(yùn)營平臺(tái)訪問等過程中未使用身份認(rèn)證管理或在登錄過程中使用弱口令,容易造成信息泄露或篡改,甚至不可估量的損失。
針對(duì)上述問題,基于我國充電樁產(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)通過商用密碼算法及其應(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)密鑰交換過程中使用臨時(shí)交互號(hào)N 與標(biāo)識(shí)符ID 來驗(yàn)證雙方的身份,抵御中間人攻擊。
(2)利用聯(lián)盟鏈技術(shù)不可篡改、去中心化、可追溯等特點(diǎn),進(jìn)行鏈上密鑰分配與管理。在鏈上密鑰分配時(shí),使用基于SM3 的HMAC 算法,確保只有擁有HMAC 密鑰且通過區(qū)塊鏈CA 認(rèn)證的實(shí)體才能獲取密鑰,保障密鑰的唯一性與可認(rèn)證性。
(3)建立新的網(wǎng)絡(luò)安全邊界[22],實(shí)現(xiàn)訪問實(shí)體的強(qiáng)身份認(rèn)證;在邊界防護(hù)、通信傳輸、身份鑒別、數(shù)據(jù)保密等方面,進(jìn)一步收窄系統(tǒng)暴露面,更細(xì)粒度地保障業(yè)務(wù)系統(tǒng)安全[23]。
本文首先描述了方案的整體架構(gòu)、闡述了主要功能模塊;其次通過實(shí)驗(yàn)驗(yàn)證了所提方案的Web 應(yīng)用、區(qū)塊鏈系統(tǒng)的性能;最后總結(jié)全文,并提出了未來工作展望。
如圖1 所示,網(wǎng)聯(lián)汽車充電樁系統(tǒng)包括訪問實(shí)體、安全網(wǎng)關(guān)、云平臺(tái)應(yīng)用服務(wù)、策略控制中心、云平臺(tái)安全防護(hù)體系支撐組件5 大模塊。
圖1 整體架構(gòu)
1.1.1 訪問實(shí)體
根據(jù)所處網(wǎng)絡(luò)域環(huá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í)體則包括軟件和硬件開發(fā)人員、服務(wù)運(yùn)維人員和測試人員等。
1.1.2 安全網(wǎng)關(guān)
安全網(wǎng)關(guān)作為實(shí)體訪問云平臺(tái)的唯一入口,負(fù)責(zé)對(duì)訪問實(shí)體進(jìn)行身份識(shí)別與訪問控制,網(wǎng)關(guān)能夠?qū)⒃L問實(shí)體與平臺(tái)資源隔離開來,使云平臺(tái)應(yīng)用服務(wù)隱藏于零信任網(wǎng)關(guān)之后,大大減少攻擊面[24-25]。同時(shí),采用先認(rèn)證后訪問的方式,只有當(dāng)訪問實(shí)體被認(rèn)證為合法身份后,才能訪問云平臺(tái)的應(yīng)用服務(wù)。此外,根據(jù)策略控制中心返回的評(píng)估結(jié)果,對(duì)訪問實(shí)體進(jìn)行訪問管理。網(wǎng)關(guān)與訪問實(shí)體和云平臺(tái)之間的通信使用商用密碼安全套接字協(xié)議(Secure Sockets Layer,SSL)保護(hù),并通過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ù)封裝而成,分為公開服務(wù)和內(nèi)網(wǎng)服務(wù)。其中,公開服務(wù)面向所有實(shí)體開放,具有良好的耦合度,負(fù)責(zé)對(duì)通過零信任安全網(wǎng)關(guān)的合法流量請(qǐng)求進(jìn)行響應(yīng),提供相應(yīng)服務(wù);內(nèi)網(wǎng)服務(wù)則只對(duì)通過強(qiáng)身份認(rèn)證的內(nèi)網(wǎng)域環(huán)境實(shí)體開放,外網(wǎng)域環(huán)境實(shí)體或未通過身份認(rèn)證的內(nèi)網(wǎng)域環(huán)境實(shí)體將無法訪問相關(guān)資源[26-28]。
1.1.4 策略控制中心
該模塊接收由安全網(wǎng)關(guān)所記錄的實(shí)體訪問行為事件,并將行為事件上鏈[29],保障行為事件的不可篡改性與可追溯性。同時(shí),決策引擎將根據(jù)行為事件和預(yù)設(shè)安全策略配置對(duì)訪問實(shí)體進(jìn)行持續(xù)驗(yàn)證、評(pí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è)備與訪問實(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ù)訪問實(shí)體的身份信息和可信任程度來管控其權(quán)限等級(jí),實(shí)現(xiàn)安全高效的權(quán)限控制機(jī)制[31]。
1.2.1 強(qiáng)身份認(rèn)證
云平臺(tái)基于B/S 架構(gòu),通過嚴(yán)格的身份認(rèn)證保障系統(tǒng)的安全性與操作的合法性[32]。身份認(rèn)證模塊由前后端不同的處理邏輯實(shí)現(xiàn)。
后端的身份認(rèn)證主要基于挑戰(zhàn)/響應(yīng)的雙向認(rèn)證機(jī)制和公鑰證書,實(shí)現(xiàn)對(duì)終端與平臺(tái)的強(qiáng)身份認(rèn)證。挑戰(zhàn)/響應(yīng)認(rèn)證機(jī)制是一系列協(xié)議的統(tǒng)稱,在該系列協(xié)議中,其中一方提出問題(挑戰(zhàn)),另一方提供有效的答案并進(jìn)行身份驗(yàn)證(響應(yīng)),只有答案有效才能通過驗(yàn)證[33],詳細(xì)認(rèn)證流程如圖2 所示。
圖2 雙向認(rèn)證流程
挑戰(zhàn)/響應(yīng)的雙向認(rèn)證具體步驟如下:首先,終端嘗試連接至云平臺(tái),身份認(rèn)證開始。終端生成一個(gè)隨機(jī)數(shù)R1作為響應(yīng)值,并將終端證書和R1發(fā)送到云平臺(tái)的網(wǎng)關(guān)。然后,網(wǎng)關(guān)驗(yàn)證接收到的證書,并使用SM2 和網(wǎng)關(guān)私鑰對(duì)R1進(jìn)行簽名,得到簽名值Sig1,并將其證書和Sig1發(fā)送到終端。當(dāng)終端接收到網(wǎng)關(guān)證書后,對(duì)其進(jìn)行驗(yàn)證。如果證書有效,終端將根據(jù)證書上攜帶的網(wǎng)關(guān)公鑰來驗(yàn)證Sig1;否則,終端對(duì)云平臺(tái)的身份認(rèn)證失敗,通信終止。當(dāng)上述過程結(jié)束時(shí),網(wǎng)關(guān)生成一個(gè)隨機(jī)數(shù)R2作為響應(yīng)值,并將其發(fā)送給終端。接下來,終端用其私鑰對(duì)R2進(jìn)行簽名,并將簽名發(fā)送到網(wǎng)關(guān)。最后,網(wǎng)關(guān)根據(jù)終端的證書驗(yàn)證Sig2。如果Sig2有效,則成功建立連接。否則,連接建立失敗,通信終止。上述過程結(jié)束則身份驗(yàn)證過程完成。
后端還采用基于JSON Web Token(JWT)的訪問控制和Spring Security 權(quán)限控制,Token 令牌隨用戶登錄而自動(dòng)獲取。此外,根據(jù)管理員賬戶與普通用戶賬戶的職能和需求的不同,通過Spring Security 來控制這兩類賬戶的不同權(quán)限,只有管理員可以進(jìn)行遠(yuǎn)程控制等操作,普通用戶只能查看訂單相關(guā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),本文所搭建的測試網(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 公鑰和私鑰,并將所生成的私鑰物理寫入充電樁的存儲(chǔ)設(shè)備中,該方式中的私鑰未參與通信,只有讀取云平臺(tái)與充電樁的存儲(chǔ)設(shè)備才能獲得私鑰,一般情況下不存在泄露風(fēng)險(xiǎn),從而起到安全地事先共享一對(duì)公私鑰的作用;最后,充電樁需要與云平臺(tái)進(jìn)行密鑰交換,該交換基于SM2 非對(duì)稱加密,所交換的密鑰為HMAC 所用密鑰[35]。HMAC 密鑰由云平臺(tái)生成,通過臨時(shí)交互號(hào)N與身份標(biāo)識(shí)符ID來進(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)共同背書,保障事件的安全可信存儲(chǔ)。由于在聯(lián)盟鏈中,不同組織之間的數(shù)據(jù)不主動(dòng)相通,從而實(shí)現(xiàn)密鑰數(shù)據(jù)與事件數(shù)據(jù)的隔離存儲(chǔ),保障密鑰數(shù)據(jù)與事件數(shù)據(jù)之間的獨(dú)立性,避免數(shù)據(jù)管理混亂。
圖5 區(qū)塊鏈測試網(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)行簽名,并通過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ù)”的方法來有效防止重復(fù)攻擊。該方法在每一條HTTP 請(qǐng)求上增加了“timeStampCode”字段,該字段由時(shí)間戳與隨機(jī)數(shù)拼接而成,時(shí)間戳根據(jù)當(dāng)前生成時(shí)間與1970 年1 月1 日之間的時(shí)間差計(jì)算而成,精確至毫秒級(jí)別,能顯著提高被成功猜測與碰撞的難度。隨機(jī)數(shù)則使用強(qiáng)隨機(jī)數(shù),采用算法SHA1PRNG 生成,以CPU 的熱噪聲、磁盤讀寫的字節(jié)、鍵盤的敲擊等現(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)成功后,開始執(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ù)庫進(jìn)行持久化存儲(chǔ)。若驗(yàn)簽失敗,則數(shù)據(jù)完整性遭到破壞,廢棄請(qǐng)求,拒絕訪問。處理流程如圖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)是配置簡單并支持動(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)控。通過設(shè)置定時(shí)任務(wù),使得充電樁在每個(gè)固定的時(shí)間間隔通過HTTP 請(qǐng)求向云平臺(tái)持續(xù)匯報(bào)狀態(tài)信息,包括硬件溫度、充電樁所處狀態(tài)(通電、斷電、鎖定)、累計(jì)充電量等數(shù)據(jù),服務(wù)信息經(jīng)過SM4 加密與SM2簽名,并附加了時(shí)間戳+隨機(jī)數(shù),能有效保障信息的完整性與真實(shí)性,防止其受到中間人攻擊與重放攻擊。
(3)遠(yuǎn)程控制。由于充電樁部署在公開環(huán)境中,因此在實(shí)際場景中,充電樁的運(yùn)行環(huán)境復(fù)雜多樣,難免會(huì)遭遇某些特殊情況,如人為損壞、自然災(zāi)害、安全漏洞等,從而需要通過臨時(shí)改變充電樁的運(yùn)行狀態(tài)來防止安全事故、財(cái)產(chǎn)損失,保護(hù)充電樁安全,基于此,亟需一種便捷高效的手段來實(shí)現(xiàn)對(duì)充電樁運(yùn)行狀態(tài)的靈活控制[5]。因此,本系統(tǒng)設(shè)計(jì)了遠(yuǎn)程控制模塊,可以通過云平臺(tái)來遠(yuǎn)程控制充電樁的運(yùn)行狀態(tài),根據(jù)序列號(hào)來選擇要進(jìn)行控制的充電樁,再根據(jù)指令cmd 來改變充電樁狀態(tài),指令與充電樁的狀態(tài)相對(duì)應(yīng),包括LOCK、ON、OFF、UNLOCK、SHUTDOWN、REBOOT,其中,LOCK 指令表示鎖定充電樁,拒絕除云平臺(tái)以外的其他所有實(shí)體的訪問,不允許用戶繼續(xù)使用充電等功能,是擁有最高優(yōu)先級(jí)的指令;ON 指令表示開啟充電樁充電功能,使充電樁進(jìn)入充電狀態(tài),但當(dāng)充電樁處于LOCK 狀態(tài)時(shí),該指令無效;OFF指令表示關(guān)閉充電樁充電功能,使充電樁停止充電;UNLOCK 指令表示解鎖充電樁,將充電樁從LOCK 狀態(tài)切換為OFF 狀態(tài),重新允許其他實(shí)體的訪問,充電樁再次進(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)程控制流程
測試軟件信息如表1 所示。測試服務(wù)器配置如表2 所示??蛻舳伺渲萌绫? 所示。
表1 測試軟件信息
表2 服務(wù)器配置
表3 客戶端配置
本實(shí)驗(yàn)的目的是檢驗(yàn)本文所設(shè)計(jì)實(shí)現(xiàn)的云平臺(tái)系統(tǒng)是否具有良好的性能,并考察在不同的用戶負(fù)載下,云平臺(tái)對(duì)用戶請(qǐng)求做出的響應(yīng)情況,以確保將來系統(tǒng)運(yùn)行的安全性、可靠性和執(zhí)行效率。
2.2.1 測試工具
采用LoadRunner 性能自動(dòng)化測試工具測試系統(tǒng)性能。通過創(chuàng)建虛擬用戶,在高并發(fā)量和模擬真實(shí)環(huán)境的背景下,實(shí)時(shí)監(jiān)控系統(tǒng)性能。
2.2.2 測試描述
對(duì)云平臺(tái)的功能進(jìn)行測試。檢驗(yàn)云平臺(tái)功能的可用性與穩(wěn)定性,在高并發(fā)、高負(fù)載的環(huán)境下測試Web 應(yīng)用的性能,觀察并統(tǒng)計(jì)吞吐量、CPU 使用率、內(nèi)存占用率等指標(biāo)。本次測試的要求是驗(yàn)證在30 分鐘內(nèi)完成2 000 次用戶登錄系統(tǒng),然后執(zhí)行開始充電、停止充電等基本業(yè)務(wù),最后退出。
2.2.3 性能指標(biāo)
各測試項(xiàng)目標(biāo)值如表4 所示。
表4 Web 性能指標(biāo)
(1)數(shù)據(jù)摘要。LoadRunner 進(jìn)行場景測試結(jié)果收集后,首先顯示該結(jié)果的一個(gè)摘要信息,如圖12所示。概要中列出了“Statistics Summary(統(tǒng)計(jì)信息摘要)”“Transaction Summary(交易摘要)”以及“HTTP Responses Summary(HTTP 請(qǐng)求響應(yīng)摘要)”等。以簡要的信息列出本次測試結(jié)果。
圖12 性能測試結(jié)果摘要
(2)結(jié)果分析。獲得上述數(shù)據(jù)后,最新的測試結(jié)果記錄如表5 所示。
表5 Web 測試結(jié)果
本次測試運(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.1 測試工具
Hyperledger Caliper 是一個(gè)開源的通用區(qū)塊鏈性能測試工具。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ì)具體的測試流程,即可獲取Caliper輸出的可視化性能測試報(bào)告??梢姄碛羞@些特點(diǎn)的Caliper,能恰好滿足項(xiàng)目中區(qū)塊鏈部分對(duì)壓測工具的需求。
2.3.2 測試標(biāo)準(zhǔn)
采用的區(qū)塊鏈標(biāo)準(zhǔn)以《可信區(qū)塊鏈第1 部分:區(qū)塊鏈技術(shù)參考架構(gòu)》《可信區(qū)塊鏈第2 部分:總體要求和評(píng)價(jià)指標(biāo)》《可信區(qū)塊鏈第3 部分:測評(píng)方法》作為參考,其中區(qū)塊鏈行業(yè)標(biāo)準(zhǔn)如表6 所示。
表6 區(qū)塊鏈行業(yè)標(biāo)準(zhǔn)
2.3.3 測試描述
為驗(yàn)證鏈上數(shù)據(jù)管理模塊的穩(wěn)定性與可用性,本測試在高并發(fā)、高負(fù)載的環(huán)境下,分別以執(zhí)行數(shù)據(jù)上鏈功能(數(shù)據(jù)存儲(chǔ))的invoke 合約與執(zhí)行鏈上查詢功能(數(shù)據(jù)獲?。┑膓uery 合約作為測試對(duì)象,通過Caliper 實(shí)時(shí)監(jiān)控測試過程中區(qū)塊鏈系統(tǒng)的每秒交易接收量以及每秒交易上鏈量,控制發(fā)送的壓力,維持兩者數(shù)值始終大體一致,使得壓力剛剛達(dá)到系統(tǒng)的瓶頸。對(duì)于尖峰沖擊,則通過增加發(fā)送的壓力,讓系統(tǒng)每秒交易接收量達(dá)到每秒上鏈量的兩倍,使得壓力遠(yuǎn)遠(yuǎn)超過系統(tǒng)的瓶頸上限,觀察系統(tǒng)在極端情況下的運(yùn)轉(zhuǎn)情況。測試方案如表7 所示。
表7 區(qū)塊鏈測試方案
(1)數(shù)據(jù)摘要。invoke 合約與query 合約的測試結(jié)果分別如圖13、圖14 所示。
圖13 invoke 合約測試結(jié)果
圖14 query 合約測試結(jié)果
將數(shù)據(jù)匯總整理后如表8 所示。
表8 測試數(shù)據(jù)
(2)結(jié)果分析。采用Caliper 對(duì)區(qū)塊鏈進(jìn)行性能測試,對(duì)交易延遲場景進(jìn)行了低負(fù)載測試,對(duì)系統(tǒng)吞吐量進(jìn)行了高負(fù)載測試,使得壓力達(dá)到系統(tǒng)的瓶頸,對(duì)尖峰沖擊場景進(jìn)行了超過瓶頸的2 倍流量沖擊測試。Caliper 自動(dòng)記錄下設(shè)定好的時(shí)間點(diǎn)的數(shù)據(jù),最終生成測試結(jié)果。如表8 中的Caliper 測試結(jié)果報(bào)告所示,本次測試的交易成功率為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。測試結(jié)果表明:本文所采用的區(qū)塊鏈方案具有良好的穩(wěn)定性,能夠滿足實(shí)際業(yè)務(wù)需求,確保鏈上數(shù)據(jù)管理功能的可用性,各項(xiàng)指標(biāo)測試均符合行業(yè)標(biāo)準(zhǔn)。
本節(jié)對(duì)前文所提解決方案進(jìn)行了具體實(shí)現(xiàn),即云平臺(tái)系統(tǒng)與區(qū)塊鏈系統(tǒng),并分別通過Web應(yīng)用性能測試與區(qū)塊鏈系統(tǒng)性能測試對(duì)所設(shè)計(jì)實(shí)現(xiàn)的云平臺(tái)系統(tǒng)與區(qū)塊鏈系統(tǒng)的性能進(jìn)行詳細(xì)測試。測試結(jié)果表明,通過本文方案所實(shí)現(xiàn)的云平臺(tái)系統(tǒng)與區(qū)塊鏈系統(tǒng)性能良好,各項(xiàng)指標(biāo)均符合所參考的測試性能基準(zhǔn),在實(shí)驗(yàn)所設(shè)的高負(fù)載與高并發(fā)環(huán)境下,仍能保證系統(tǒng)功能的穩(wěn)定性和可用性,能夠滿足實(shí)際業(yè)務(wù)需求,符合預(yù)期目標(biāo)。
隨著電動(dòng)汽車充電設(shè)施的日益數(shù)字化和智能化,網(wǎng)聯(lián)汽車充電樁的信息安全已成為不容小覷的問題。本文對(duì)網(wǎng)聯(lián)汽車充電樁與管理云平臺(tái)的安全開展了重點(diǎn)研究,設(shè)計(jì)實(shí)現(xiàn)了基于商用密碼與區(qū)塊鏈的網(wǎng)聯(lián)汽車充電樁安全系統(tǒng)??刹僮餍苑矫?,系統(tǒng)采用主流開發(fā)框架與科學(xué)設(shè)計(jì)模式,通過B/S 架構(gòu)實(shí)現(xiàn)服務(wù)的解耦開發(fā)、便捷維護(hù)、安全升級(jí)和穩(wěn)定訪問,提升用戶使用體驗(yàn);安全性方面,系統(tǒng)采用商用密碼算法SM2、SM3、SM4,基于國密版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)證策略。