《電動汽車充換電服務(wù)信息交換》第四部分.

1、ICS 35.240.60L 73T/CEC中國電力企業(yè)聯(lián)合會標(biāo)準(zhǔn)T/CEC XXXX XXXXX電動汽車充換電服務(wù)信息交換第4部分：數(shù)據(jù)傳輸與安全Charging and battery swap service data interactive for electric vehiclePart4： Data exchange and Security（征求意見稿）XXXX XX- XX發(fā)布XXXX XX- XX實(shí)施中國電力企業(yè)聯(lián)合會標(biāo)準(zhǔn)T/CEC XXXXX 201X目 次目次I前言II引言I1范圍12規(guī)范性引用文件 13術(shù)語和定義14數(shù)據(jù)傳體系 14.1 概述14.2 數(shù)據(jù)傳輸一般流程

2、24.3 數(shù)據(jù)傳輸接口白基本要求 25平臺認(rèn)證方式及規(guī)則 25.1 概述25.2 平臺認(rèn)證模式 25.3 平臺認(rèn)證方法 35.4 傳輸方式及規(guī)則 36.1 數(shù)據(jù)傳輸接口規(guī)則 36.2 接口調(diào)用方式 46.3 消息頭規(guī)范46.4 消息主體規(guī)范 46.5 批量數(shù)據(jù)傳輸56.6 返回參數(shù)規(guī)則 56.7 的使用及管理 67.1 基本安全要求 67.2 密鑰的安全要求 67.2.1 密鑰的產(chǎn)生 67.2.2 密鑰的分發(fā) 67.2.3 密鑰的存儲 67.2.4 密鑰的銷毀 67.3 數(shù)據(jù)的加密處理 67.3.1 數(shù)據(jù)加密規(guī)則 67.3.2 數(shù)據(jù)加/解密方法 77.3.3 數(shù)據(jù)加/解密示例 8附錄A （資料

3、性附錄）數(shù)字信封密鑰分發(fā)方式 10電動汽車充換電服務(wù)信息交換分為四個部分： 第1部分：總則； 第2部分：公共信息交換規(guī)范； 第3部分：業(yè)務(wù)信息交換規(guī)范； 第4部分：數(shù)據(jù)傳輸及安全；本規(guī)范為第4部分。本規(guī)范按照GB/T 1.1-2009 給出的規(guī)則編寫。請注意本規(guī)范中的某些內(nèi)容可能涉及專利。本規(guī)范的發(fā)布機(jī)構(gòu)不承擔(dān)識別這些專利的責(zé)任。本規(guī)范由中國電力企業(yè)聯(lián)合會提出。本規(guī)范由能源行業(yè)電動汽車充電設(shè)施標(biāo)準(zhǔn)化技術(shù)委員會歸口。本規(guī)范主要起草單位：本規(guī)范參加起草單位：本規(guī)范主要起草人：本標(biāo)準(zhǔn)為首次制定。本標(biāo)準(zhǔn)在執(zhí)行過程中的意見或建議反饋至中國電力企業(yè)聯(lián)合會標(biāo)準(zhǔn)化中心（北京市白廣路二條一 號,100761）。

4、#/T XXXXX-XXXX為加快電動汽車充電基礎(chǔ)設(shè)施建設(shè)，促進(jìn)不同充電服務(wù)平臺互聯(lián)互通，構(gòu)建充電基礎(chǔ)設(shè)施信息服務(wù)信息交換體系架構(gòu)， 統(tǒng)一信息接口通信協(xié)議， 實(shí)現(xiàn)不同充電運(yùn)營企業(yè)、 不同區(qū)域的充電服務(wù)設(shè)施、 第三 方平臺信息資源等互聯(lián)和充分利用，實(shí)現(xiàn)充電設(shè)施網(wǎng)絡(luò)服務(wù)平臺間數(shù)據(jù)交換，充電系統(tǒng)服務(wù)功能跨平臺信息交換服務(wù)，特制定本標(biāo)準(zhǔn)。I/T XXXXX XXXX電動汽車充換電服務(wù)信息交換第4部分：數(shù)據(jù)傳輸與安全1范圍本部分規(guī)定了電動汽車充換電服務(wù)信息交換的數(shù)據(jù)傳輸規(guī)范和安全要求，包含充換電服務(wù)信息交換的平臺認(rèn)證規(guī)范、數(shù)據(jù)傳輸規(guī)范和數(shù)據(jù)傳輸安全要求。本部分適用于歸屬不同運(yùn)營商的電動汽車充換電運(yùn)營服務(wù)

5、平臺之間的充換電服務(wù)信息交換，以及電動汽車充換電運(yùn)營服務(wù)平臺與其他第三方服務(wù)及管理平臺之間的信息交換。2規(guī)范性引用文件卜列文件對于本文件的應(yīng)用是必不可少的。凡是注日期的引用文件， 僅所注日期的版本適用于本文 件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。GB/T 19596-2004 :電動汽車術(shù)語GB/T 29317-2012 :電動汽車充換電設(shè)施術(shù)語GB/T 2260-2007 中華人民共和國行政區(qū)域代碼GB 11714-1997全國組織機(jī)構(gòu)代碼編制規(guī)則GB/T 31286-2014 全國組織機(jī)構(gòu)代碼與名稱GB/T 18391.1-2002 信息技術(shù) 數(shù)據(jù)元的規(guī)范

6、與標(biāo)準(zhǔn)化第1部分：數(shù)據(jù)元的規(guī)范與標(biāo)準(zhǔn)化框架GB/T 9387.1-1998 信息技術(shù) 開放系統(tǒng)互聯(lián) 基本參考模型 第1部分：基本模型GB/T 7408-2005GB/T 22239-2008GB/T 25070-2010GB/T 20271-2006GB/T 20988-2007GB/T 19596-2004數(shù)據(jù)元和交換格式信息交換日期和時間表示法 信息安全技術(shù)信息系統(tǒng)安全等級保護(hù)基本要求 信息安全技術(shù)信息系統(tǒng)等級保護(hù)安全設(shè)計(jì)技術(shù)要求 信息安全技術(shù)信息系統(tǒng)安全通用技術(shù)要求 信息安全技術(shù)信息系統(tǒng)災(zāi)難恢復(fù)規(guī)范 電動汽車術(shù)語3術(shù)語和定義GB/T 19596、GB/T 29317、GB/Z 19027

7、-2005以及電動汽車充換電服務(wù)信息交換第1部分：總則中定義的以及下列術(shù)語和定義適用于本文件。4數(shù)據(jù)傳輸體系4.1 概述數(shù)據(jù)傳輸體系要求了參與電動汽車充換電服務(wù)的各角色和實(shí)體之間應(yīng)在正常、安全、有效的原則下通過規(guī)范的接口進(jìn)行信息交換，相互協(xié)同地向電動汽車用戶提供充換電服務(wù)。相關(guān)實(shí)體及其之間的信息交換接口參見電動汽車充換電服務(wù)信息交換第1部分：總則。電動汽車充換電服務(wù)信息通過數(shù)據(jù)傳輸接口進(jìn)行交換，數(shù)據(jù)傳輸接口眾多，既存在于各個服務(wù)邏輯層之間，也存在于同一邏輯層的不同管理域之間， 數(shù)據(jù)傳輸接口可通過身份認(rèn)證、 訪問控制、數(shù)據(jù)加密、 數(shù)字簽名等安全措施，保障數(shù)據(jù)傳輸過程中要保障所傳輸數(shù)據(jù)的機(jī)密性和安

8、全性。4.2 數(shù)據(jù)傳輸一般流程4.3 數(shù)據(jù)傳輸接口的基本要求電動汽車充換電服務(wù)信息交換應(yīng)根據(jù)國家信息安全等級保護(hù)相關(guān)要求。運(yùn)營商須提供嚴(yán)格的系統(tǒng)安全保密機(jī)制，保障信息交換接口安全、穩(wěn)定、可靠地運(yùn)行，包括信息的存取控制、應(yīng)用系統(tǒng)操作的安全等?；疽螅?)采用身份認(rèn)證、訪問控制、數(shù)據(jù)加密、數(shù)字簽名等安全措施；2)采用安全可靠并且普遍使用的加密算法；3)密鑰的存貯和交易信息的加密/解密需要在安全的環(huán)境中；4)遵循數(shù)據(jù)安全保密的國家和行業(yè)標(biāo)準(zhǔn)；5)定期更換密鑰；6)具備對報(bào)文做來源正確性鑒別的機(jī)制(HMAC 。5平臺認(rèn)證方式及規(guī)則5.1 概述電動汽車充換電服務(wù)信息交換應(yīng)具備平臺認(rèn)證服務(wù)提供平臺之間的

9、鑒權(quán)認(rèn)證功能。平臺之間在信息交換前，需完成平臺認(rèn)證，獲得平臺交換能力。5.2 平臺認(rèn)證模式平臺認(rèn)證支持分布式認(rèn)證模式和中心交換認(rèn)證模式。分布式認(rèn)證模式由運(yùn)營商之間進(jìn)行鑒權(quán)認(rèn)證，運(yùn)營商之間確定運(yùn)營商標(biāo)識( OperatorlD )、運(yùn)營商 密鑰(Operator_Secret )和消息密鑰(Data_Secret ),具體認(rèn)證方式可由運(yùn)營商協(xié)商確定。中心交換認(rèn)證模式由統(tǒng)一的認(rèn)證服務(wù)方提供鑒;權(quán)認(rèn)證服務(wù)，運(yùn)營商與中心認(rèn)證服務(wù)方確定運(yùn)營商標(biāo)識(OperatorlD )、運(yùn)營商密鑰(Operator_Secret )和消息密鑰(Data_Secret ),具體認(rèn)證方式由各運(yùn) 營商和認(rèn)證服務(wù)方共同確定。

10、Ji運(yùn)營服務(wù)平臺B圖3中心交換認(rèn)證模式5.3 平臺認(rèn)證方法平臺認(rèn)證宜采取身份認(rèn)證和訪問控制相結(jié)合的方式進(jìn)行。身份認(rèn)證可采取用戶名/ 口令認(rèn)證、密鑰認(rèn)證或數(shù)字證書認(rèn)證等方式進(jìn)行；訪問控制可采取IP訪問控制、時間訪問控制等多種手段結(jié)合。用戶身份認(rèn)證成功后授予 Token,每次向服務(wù)端請求資源的時候需要帶著服務(wù)端簽發(fā)的Token,服務(wù)端驗(yàn)證Token成功后，才返回請求的數(shù)據(jù)。Token的有效期不宜大于7天，Token丟失或失效后需要再次發(fā) 起認(rèn)證服務(wù)。訪問控制發(fā)送身份信息請求發(fā)起方認(rèn)證服務(wù)返回Token認(rèn)證成功圖4平臺認(rèn)證方式6數(shù)據(jù)傳輸方式及規(guī)則6.1 數(shù)據(jù)傳輸接口規(guī)則所有數(shù)據(jù)傳輸接口均采用HTTP

11、(S)接口，每個接口的URL勻采用如下格式定義：http(s):譏域名/evcs/v 版本號/接口名稱1)域名：各接入運(yùn)營商所屬域名。2)版本號：代表接口版本號，不同的版本地址對應(yīng)相應(yīng)版本代碼。系統(tǒng)升級期間，新舊版本可同時 存在，待所有接入方都切換到新接口，舊接口即可下線。從而達(dá)到平滑升級的目的。3)接口名稱：所請求/調(diào)用接口的名稱，具體接口名稱見 電動汽車充換電服務(wù)信息交換第2部分:公共信息交換規(guī)范和電動汽車充換電服務(wù)信息交換第3部分：業(yè)務(wù)信息交換規(guī)范。為保證各接口的功能明確清晰，每個UR1X允許對應(yīng)一種功能。其中測試?yán)诸?/T XXXXX XXXX6.2 接口調(diào)用方式所有接口均使用HTT

12、P(S)/POS訪'式傳輸參數(shù)，傳輸過程中應(yīng)包含消息頭和消息主體兩部分。6.3 消息頭規(guī)范消息頭一般需包含內(nèi)容類型，內(nèi)容類型(Content-Type )字段用于標(biāo)識請求中的消息主體的編碼方式，本標(biāo)準(zhǔn)中所規(guī)范的信息交換內(nèi)容均采用JSONJ方式，參數(shù)信息采用 utf-8編碼，因此需要配置消息頭中的 Content-Type 為application/json;charset=utf-8 。6.4 消息主體規(guī)范6.4.1 消息主體的組成消息主體是信息交換過程中的具體內(nèi)容，一般由運(yùn)營商標(biāo)識( OperatorID )、憑證(Token)、參 數(shù)內(nèi)容(Data)、時間戳(TimeStamp)和

13、數(shù)字簽名(Sig)組成。表1消息主體內(nèi)容表參數(shù)名說明舉例Token業(yè)務(wù)執(zhí)行的憑證Data各接口具體參數(shù)信息Data:stationID :充電立I ID,'platformID ':歸屬運(yùn)營平臺所有方ID,xxxxxxxxx,stationID :充電立I ID,'platformID ':歸屬運(yùn)營平臺所有方ID,xxxxxxxxx,TimeStamp時間戳接口請求時時間戳信息，格式為 yyyyMMddHHmmssSig參數(shù)簽名6.4.2參數(shù)簽名規(guī)則參數(shù)簽名采用HMAC-MD5法，采用MD昨?yàn)樯⒘泻瘮?shù)，通過密鑰(Operator_Secret )對整個消息主 體

14、進(jìn)行加密，然后采用Md5言息摘要的方式形成新的密文。(1) HMAC-MD5法HMAC(K, M =H (K opad I H ( K® ipad I M)其中：K是密鑰(Operator_Secret ),長度可為64字節(jié)，若小于該長度，在密鑰后面用“0"補(bǔ)齊。M 是消息內(nèi)容；H 是散列函數(shù)；opad 和Ipad分別是由若干個0x5c和0x36組成的字符串；表示異或運(yùn)算；I表示連接操作。(2) HMAC-MD5程1)在密鑰(Operator_Secret )后面添加0來創(chuàng)建一個長為64字節(jié)的字符串(str);2)將上一步生成的字符串(str)與ipad(0x36)做異或運(yùn)

15、算，形成結(jié)果字符串(istr);3)將消息內(nèi)容data附加到第二步的結(jié)果字符串(istr)的末尾；4)做md5!算于第三步生成的數(shù)據(jù)流(istr);5)將第一步生成的字符串(str)與opad(0x5c)做異或運(yùn)算，形成結(jié)果字符串(ostr);6)再將第四步的結(jié)果(istr)附加到第五步的結(jié)果字符串(ostr)的末尾；7)做md5!算于第六步生成的數(shù)據(jù)流(ostr),輸出最終結(jié)果(out)。6.4.3參數(shù)傳遞要求參數(shù)傳遞過程中的所有參數(shù)都要先進(jìn)行urlencode轉(zhuǎn)義，然后再按照key=value格式使用&連接在一起。6.5 批量數(shù)據(jù)傳輸數(shù)據(jù)傳輸接口中的 Data字段可為數(shù)組型的JSO

16、瞪式，數(shù)據(jù)發(fā)送方可通過該字段實(shí)現(xiàn)批量數(shù)據(jù)的傳 輸。6.6 返回參數(shù)規(guī)則數(shù)據(jù)傳輸接口的返回參數(shù)包括兩個部分：ret, msg 。1)ret:必填字段，返回編碼參考下表。2)msg:可選字段，當(dāng)ret!=0是存在，表示具體錯誤信息。3)采用utf-8編碼，JSO略式。4)舉例： ret ' : 401, misg' :Invalid signature ', 表2返回參數(shù)編碼表Ret值說明-1系統(tǒng)繁忙，此時請求方稍后重試0請求成功401簽名錯誤402Token錯誤403POS慘數(shù)不合法，缺少必須的示例：OperatorID,sig,TimeStamp,Data 四個參數(shù)40

17、4請求的業(yè)務(wù)參數(shù)不合法，各接口定義自己的必須參數(shù)500系統(tǒng)錯誤7密鑰的使用及管理各運(yùn)營商系統(tǒng)間在消息傳遞時，需要保障傳輸和接收數(shù)據(jù)的安全和完整。7.1 基本安全要求運(yùn)營商必須滿足數(shù)據(jù)安全傳輸控制方面的要求。運(yùn)營商必須提供嚴(yán)格的系統(tǒng)安全保密機(jī)制，保障信息交換接口安全、穩(wěn)定、可靠地運(yùn)行，包括信息的存取控制、應(yīng)用系統(tǒng)操作的安全等。7.2 密鑰的安全要求密碼算法用于密鑰的產(chǎn)生、分發(fā)、HMA©及加密等安全功能，相關(guān)的算法模塊在其生命周期內(nèi)不能 被修改、導(dǎo)出至安全環(huán)境外部。指定功能的密鑰僅能做指定功能使用，不能被其他任何功能使用。7.2.1 密鑰的產(chǎn)生數(shù)據(jù)密鑰應(yīng)具備隨機(jī)產(chǎn)生特性，密鑰產(chǎn)生后要檢查

18、密鑰的有效性，弱密鑰和半弱密鑰需被剔除。運(yùn)營商加入信息交換時，必須申請獨(dú)立的密鑰文件，密鑰可由運(yùn)營商協(xié)商產(chǎn)生。7.2.2 密鑰的分發(fā)密鑰的分發(fā)應(yīng)該由安全方式進(jìn)行，可通過聯(lián)機(jī)報(bào)文或數(shù)字信封的方式加密傳輸。7.2.3 密鑰的存儲密鑰宜保存在硬件加密機(jī)內(nèi)。如果出現(xiàn)在硬件加密機(jī)外，則必須密文方式出現(xiàn)。密鑰注入、密鑰管理和密鑰檔案的保管應(yīng)由專人負(fù)責(zé)。使用密鑰和銷毀密鑰要在監(jiān)督下進(jìn)行并應(yīng)有使用、銷毀記錄。7.2.4 密鑰的銷毀當(dāng)新密鑰產(chǎn)生后，生命期結(jié)束的舊密鑰必須從數(shù)據(jù)庫和內(nèi)存中清除，防止被替換使用；同時所有可能重新構(gòu)造此密鑰的信息也必須清除。新密鑰成功啟用和舊密鑰自動銷毀的記錄將被更新。7.3 數(shù)據(jù)的加

19、密處理每個運(yùn)營商交互前需要分配 運(yùn)營商標(biāo)識(OperatorlD )、運(yùn)營商密鑰(Operator_Secret )和消 息密鑰(Data_Secret )。1)運(yùn)營商標(biāo)識(OperatorlD ):固定眼，運(yùn)營商的組織機(jī)構(gòu)代碼，作為運(yùn)營商的唯一標(biāo)示。2)運(yùn)營商密鑰(Operator_Secret ):可采用32H、48H和64H,由0-F字符組成，為簽名的加密密鑰。3)消息密鑰(Data_Secret ):用于對所有接口中 Data信息進(jìn)行加密。7.3.1 數(shù)據(jù)加密規(guī)則消息發(fā)送方需要對 Data字段中涉及交易及隱私等數(shù)據(jù)利用消息密鑰( Data_Secret )進(jìn)行加密，加密算法宜使用AE劭

20、口密。消息接收方收到消息之后，根據(jù)消息密鑰( Data_Secret )對消息體中的Data數(shù)據(jù)進(jìn)行解密，校驗(yàn) 參數(shù)合法性等后續(xù)業(yè)務(wù)處理。7.3.2 數(shù)據(jù)加/解密方法數(shù)據(jù)傳輸?shù)募用苁褂脤ΨQ加密算法AE劭口密，AESBT法的密鑰長度、分組長度和輪數(shù)的關(guān)系如表3所示。表 3 Key-Block-Round 關(guān)系密鑰長度(Nk words)分組長度(Nb words)輪數(shù)(Nr)441064128414對于AESm密和解密變換，AEST法使用的輪函數(shù)由4個不同的以字節(jié)為基本單位的變換復(fù)合而成, 該過程由四個不同的階段組成：1)S盒變換，用一個S盒完成分組中的按字節(jié)代替；2)行移位變換，一個簡單的置換

21、；3)列混淆變換，一個利用在域 GF(28)上的算術(shù)性的代替；4)輪密鑰加變換，一個利用當(dāng)前分組和擴(kuò)展密鑰的一個部分進(jìn)行按位異或。AES寸數(shù)據(jù)的加密過程是通過把輸入的明文和密鑰由輪函數(shù)經(jīng)Nr輪迭代來實(shí)現(xiàn)的，結(jié)尾輪與前 Nr-1輪不同。前Nr-1輪依次進(jìn)行S盒變換、行移位變換、列混淆變換和輪密鑰加變換；結(jié)尾輪與前Nr-1輪相比去掉了列混淆變換。而解密過程與加密過程相反，通過把輸入的密文和密鑰由輪函數(shù)經(jīng)Nr輪迭代來實(shí)現(xiàn)的，結(jié)尾輪與前Nr-1輪不同。前Nr-1輪依次進(jìn)行逆行移位變換、逆 S盒變換、輪密鑰加變換和逆列混淆變換；結(jié)尾輪與 前Nr-1輪相比去掉了逆列混淆變換。AE算法的加密解密過程如圖 5

22、所示。加密解密圖5 AES加/解密過程圖7.3.3 數(shù)據(jù)加/解密示例密鑰：1234567890abcdef明文信息：示例： "total":1,"stationStatusInfo":"operationID":"123456789","stationID":"111111111111111","connectorStatusInfos":"connectorID":1,"equipmentID":"100

23、00000000000000000001","status":4, "currentA":0,"currentB":0,"currentC":0,"voltageA":0,"voltageB":0,"voltageC":0,"soc":10,秘文：示例： DHVWF+8xRIfU7nUCNQdLaGF15VaMZWtNcwaqeumUPe/ok9zgSkR0pbOJUmYYQs7ZFMN7GhLB 1ywEN3kb1gH4z+

24、Mc2Z4rQe8Xa42LrmkDRvwwosmVMuR+mbLFCG+Xf5unkRO6JJx1PiTAxAB6o yWqUmbOKskK81LqpWBU5fKnBZwXo3jv2hnKItwCODYw+B+Pg+0IzZ5ye5cKcwz99NO5/H2gU0scZhn+rl8Jcktbm42TVklnxdzG/aw200H2z9ugpB1q2X0sGAi55SQH3DbLpWb5oQE5vy0As7lje4e +4dE8vbLIR0dMw8/lA9cBPYRO2WOkH6SFwFUyi+IishP8j+mzEcfoyAOIUSh5G/5VYqlYu1zlVUsYCHWu7MTE1Gr55