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

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

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

4、#/T XXXXX-XXXX為加快電動汽車充電基礎設施建設，促進不同充電服務平臺互聯互通，構建充電基礎設施信息服務信息交換體系架構， 統一信息接口通信協議， 實現不同充電運營企業、 不同區域的充電服務設施、 第三 方平臺信息資源等互聯和充分利用，實現充電設施網絡服務平臺間數據交換，充電系統服務功能跨平臺信息交換服務，特制定本標準。I/T XXXXX XXXX電動汽車充換電服務信息交換第4部分：數據傳輸與安全1范圍本部分規定了電動汽車充換電服務信息交換的數據傳輸規范和安全要求，包含充換電服務信息交換的平臺認證規范、數據傳輸規范和數據傳輸安全要求。本部分適用于歸屬不同運營商的電動汽車充換電運營服務

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

6、與標準化第1部分：數據元的規范與標準化框架GB/T 9387.1-1998 信息技術 開放系統互聯 基本參考模型 第1部分：基本模型GB/T 7408-2005GB/T 22239-2008GB/T 25070-2010GB/T 20271-2006GB/T 20988-2007GB/T 19596-2004數據元和交換格式信息交換日期和時間表示法 信息安全技術信息系統安全等級保護基本要求 信息安全技術信息系統等級保護安全設計技術要求 信息安全技術信息系統安全通用技術要求 信息安全技術信息系統災難恢復規范 電動汽車術語3術語和定義GB/T 19596、GB/T 29317、GB/Z 19027

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22、所示。加密解密圖5 AES加/解密過程圖7.3.3 數據加/解密示例密鑰：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