电动汽车充换电服务信息交换 第4部分：数据传输与安全
Interactive of charging and battery swap service information for electric vehicle Part 4:Data transmission and security
目 次
前言 Ⅱ
1 范 围 1
2 规范性引用文件 1
3 术语和定义 1
4 数据传输体系 1
4.1 数据传输一般流程 1
4.2 数据传输接口 1
4.3 接口调用方式 2
4.4 消息头规范 2
4.5 消息主体规范 2
4.6 重发机制 3
4.7 批量数据传输 3
5 平台认证要求 3
5.1 基本要求 3
5.2 平台认证方式及规则 4
6 密钥的管理和使用 4
6.1 基本要求 4
6.2 密钥的分类 5
6.3 密钥的管理 5
6.4 密钥的使用 5
附录 A (规范性附录) 分布式认证的认证接口规范 6
附录 B (资料性附录) 数据加解密方式 7
附录C (资料性附录) HMAC -MD5参数签名方式 8
前 言
T/CEC102《电动汽车充换电服务信息交换》共分为四个部分：
——第1部分：总则；
——第2部分：公共信息交换规范；
——第3部分：业务信息交换规范；
——第4部分：数据传输及安全。
本部分为T/CEC 102 的第4部分。
本部分按照GB/T1.1—2009《标准化工作导则 第1部分：标准的结构和编写》给出的规则起草。 本部分由中国电力企业联合会提出。
本部分由能源行业电动汽车充电设施标准化技术委员会归口。
本部分主要起草单位：国家电网公司、国网电动汽车服务有限公司。
本部分参加起草单位：普天新能源有限责任公司、青岛特来电新能源有限公司、深圳充电网科技 有限公司、中创三优(北京)科技有限公司、万帮新能源投资集团有限公司、南瑞集团、国电南瑞科 技股份有限公司、国网信息通信产业集团有限公司、许继集团、中国电力科学研究院、北京伟杰海泰 系统集成技术有限公司、深圳科陆电子科技股份有限公司。
本部分主要起草人：姜雪明、沈建新、李宝森、朱炯、秦俭、马建伟、严辉、李晓强、傅晶、黄 伟、王振飞、陈晓楠、倪峰、杨晓瑜、汪锴、李健、赵翔、杨帆、陈云飞、于婷、马胜国、左安太、 武伟会。
本标准为首次发布。
本标准在执行过程中的意见或建议反馈至中国电力企业联合会标准化管理中心(北京市白广路二 条一号，100761)。
电动汽车充换电服务信息交换
第4部分：数据传输与安全
1 范围
本部分确立了电动汽车充换电服务信息交换的数据传输和安全防护的一般原则，包含充换电服务 信息交换的数据传输体系、平台认证要求、密钥的管理和使用要求。
本部分适用于不同运营商服务平台之间的充换电服务信息交换，以及电动汽车充换电服务平台与 第三方服务及管理平台之间的信息交换。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文 件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 7408 数据和交换格式 信息交换 日期和时间表示法
GB/T9387.1 信息技术 开放系统互连 基本参考模型 第1部分：基本模型
GB/Z19027—2005 GB/T19001—2000 的统计技术指南
GB/T 19596—2004 电动汽车术语
GB/T 25070 信息安全技术 信息系统等级保护安全设计技术要求
GB/T 20271 信息安全技术 信息系统通用安全技术要求
GB/T 22239 信息安全技术 信息系统安全等级保护基本要求
GB/T 29317—2012 电动汽车充换电设施术语
T/CEC 102.1—2016 电动汽车充换电服务信息交换 第1部分：总则
T/CEC102.2 电动汽车充换电服务信息交换 第2部分：公共信息交换规范
T/CEC102.3 电动汽车充换电服务信息交换 第3部分：业务信息交换规范
3 术语和定义
GB/T 19596—2004、GB/T 29317—2012、GB/Z 19027—2005 以及T/CEC 102.1—2016 界定的术语 和定义适用于本文件。
4 数据传输体系
4.1 数据传输一般流程
电动汽车充换电服务信息交换应符合 GB/T 9387.1 中关于会话连接的要求， 一般需要经过平台认 证、请求和应答3个步骤。
4.2 数据传输接口
所有数据传输接口均采用HTTP(S)接口，每个接口的URL 均采用如下格式定义：
http(s):// [域名]/evcs/v [版本号]/[接口名称]
a)域名：各接入运营商所属域名。
b)版本号：代表接口版本号，不同的版本地址对应相应版本代码。系统升级期间，新旧版本可同时存在，待所有接入方都切换到新接口，旧接口即可下线。从而达到平滑升级的目的。
c)接口名称：所请求/调用接口的名称，具体接口名称见T/CEC102.2 和 T/CEC 102.3。
为保证各接口的功能明确清晰，每个URL 只允许对应一种功能。
4.3 接口调用方式
所有接口均使用 HTTP(S)/POST方式传输参数，采用 JSON 的方式，传输过程中应包含消息头和消息主体两部分。
4.4 消息头规范
消息头一般需包含内容类型和授权信息 (Authorization)。
内容类型 (Content-Type) 字段用于标识请求中的消息主体的编码方式，本标准中所规范的信息交 换内容均采用 JSON 的方式，参数信息采用 UTF-8 编码，因此需要配置消息头中的 Content-Type 为application/json;charset=utf-8。
授权信息 (Authorization)字段用于证明客户端有权查看某个资源，本标准中所规范的授权信息采 用令牌 (Token)的方式，因此需要在配置消息头中的 Authorization 为 Bearer Tonken。
4.5 消息主体规范
4.5.1 服务申请
一般由运营商标识 (OperatorlD) 、参数内容 (Data) 、时间戳 (TimeStamp) 、自增序列 (Seq)和数字签名 (Sig)组成。消息主体内容表见表1。
4.5.2 参数返回
数据传输接口的返回参数一般由返回值 (Ret)、 返回信息 (Msg)、参数内容 (Data) 和数字签名 (Sig)组成。
a)Ret: 必填字段，返回参数编码参考表2。
b)Msg: 必填字段，有错误表示具体错误信息，无错误返回成功信息。
c)Data: 参数内容，具体返回参数见T/CEC 102.2和 T/CEC 102.3, 所有数据采用UTF-8 编码， JSON 格式，
4.6 重发机制
数据传输过程中应设置重发机制，重发次数应大于3次，重发周期宜为1min。
4.7 批量数据传输
数据传输接口中的 Data 字段可为数组型的 JSON 格式，数据发送方可通过该字段实现批量数据的 传输。
5 平台认证要求
5.1 基本要求
电动汽车充换电服务信息交换应根据国家信息安全等级保护相关要求。
电动汽车充换电服务信息交换应具备平台认证服务提供平台之间的鉴权认证功能。平台之间在信 息交换前，需完成平台认证，获得平台交换能力。
运营商须提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息 的存取控制、应用系统操作的安全等。基本要求：
a)采用身份认证、访问控制、数据加密、数字签名等安全措施；
b)采用安全可靠并且普遍使用的加密算法；
c)密钥的存储和交易信息的加密/解密需要在安全的环境中；
d)遵循数据安全保密的国家和行业标准；
e)定期更换密钥；
f)具备对报文做来源正确性鉴别的机制 (HMAC)。
5.2 平台认证方式及规则
5.2.1 平台认证模式
平台认证应支持分布式认证模式或中心交换认证模式，具体结构如图1所示。
分布式认证模式由运营商之间进行鉴权认证，具体认证方式可由运营商协商确定。中心交换认证 模式由统一的认证服务方提供鉴权认证服务，具体认证方式由各运营商和认证服务方共同确定。
5.2.2 平台认证方法
平台认证宜采取身份认证和访问控制相结合的方式进行，相关流程如图2所示。
身份认证可采取用户名/口令认证、密钥认证或数字证书认证等方式进行；访问控制可采取 IP 访 问 控制、时间访问控制等多种手段结合。
用户身份认证成功后授予 Token, 每次向服务端请求资源的时候需要带着服务端签发的 Token, 服 务端验证 Token 成功后，才返回请求的数据。Token的有效期由服务方确定，最长不应超过7 天 ，Token 丢失或失效后需要再次发起认证服务。分布式认证的认证接口规范见附录A。
6 密钥的管理和使用
6.1 基本要求
运营商应符合GB/T25070、GB/T20271、GB/T22239 中关于数据安全传输控制方面的要求。
运营商应提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息 的存取控制、应用系统操作的安全等。
密码算法用于密钥的产生、分发、HMAC 以及加密等安全功能，相关的算法模块在其生命周期内 不能被修改、导出至安全环境外部。
指定功能的密钥仅能做指定功能使用，不能被其他任何功能使用。
6.2 密钥的分类
每个运营商交互前需要分配运营商标识、运营商密钥、消息密钥、消息密钥初始化向量和签名密 钥。具体要求如下：
a) 运营商标识 (OperatorlD): 固定9位，运营商的组织机构代码，作为运营商的唯一标示。
b)运营商密钥 (OperatorSecret):可采用32H 、48H和64H, 由0 -F 字符组成，为申请认证使用。
c)消息密钥 (DataSecret):用于对所有接口中 Data 信息进行加密。
d)消息密钥初始化向量 (DataSecretIV):固定16位，用户AES 加密过程的混合加密。
e)签名密钥 (SigSecret): 可采用32H 、48H 和64H, 由0 -F 字符组成，为签名的加密密钥。
6.3 密钥的管理
6.3.1 密钥的产生
数据密钥应具备随机产生特性，密钥产生后要检查密钥的有效性，弱密钥和半弱密钥需被剔除。 运营商加入信息交换时，必须申请独立的密钥文件，密钥可由运营商协商产生。
6.3.2 密钥的分发
密钥的分发应由安全方式进行，可通过线下分发、联机报文或数字信封的方式加密传输。
6.3.3 密钥的存储
密钥宜保存在硬件加密机内。如果出现在硬件加密机外，则密钥应以密文方式出现。
密钥注入、密钥管理和密钥档案的保管应由专人负责。使用密钥和销毁密钥要在监督下进行并应 有使用、销毁记录。
6.3.4 密钥的销毁
当新密钥产生后，生命期结束的旧密钥应从数据库和内存中清除，防止被替换使用；同时所有可 能重新构造此密钥的信息也应清除。新密钥成功启用和旧密钥自动销毁的记录将被更新。
6.4 密钥的使用
6.4.1 数据的加解密处理
消息发送方需要对 Data 字段中涉及交易及隐私等数据利用消息密钥 (DataSecret) 进行加密。
消息接收方收到消息之后，根据消息密钥 (DataSecret) 对消息体中的 Data 数据进行解密，校验参 数合法性等后续业务处理。具体加解密方法和示例参见附录 B。
6.4.2 参数签名规范
参数签名采用 HMAC-MD5 算法，采用 MD5 作为散列函数，通过签名密钥 (SigSecret) 对整个消 息主体进行加密，然后采用MD5 信息摘要的方式形成新的密文，参数签名要求大写。
参数签名顺序按照消息体顺序拼接后执行，拼接顺序为运营商标识 (OperatorlD) 、参数内容 (Data) 、时间戳 (TimeStamp) 、自增序列 (Seq) 。HMAC-MD5 具体参数签名方法和示例参见附录C。
附 录 A
(规范性附录)
分布式认证的认证接口规范
A.1 概述
此接口用于平台之间认证 Token的申请， Token 作为全局唯一凭证，调用各接口时均需要使用。
A.2 接口定义
接口名称： query_token
接口使用方法：由服务端实现此接口，由需求端调用。
A.3 输入参数
平台认证输入参数表见表 A.1。
A.4 返回值
平台认证返回值表见表 A.2。
附 录 B
(资料性附录)
数据加解密方式
B.1 数据加解密方法
数据传输的加解密使用对称加解密算法 AES 128 位加解密，加解密模式采用 CBC, 填充模式采用 PKCS5Padding 方式。
B.2 数据加解密示例
示例密钥：
1234567890abcdef
示例初始向量：
1234567890abcdef
示例明文信息
示例：
{"total":1,"stationStatusInfo":{"operationID":"123456789","stationID":"111111111111111",
"connectorStatusInfos": {"connectorlD": 1,"equipmentID":"10000000000000000000001", "status":4,"currentA":0,"currentB":0,"currentC":0,"voltageA":0,"voltageB":0,
"voltageC":0,"soc":10,}}}
示例秘文：
il7BOBSEjFdzpyKzfOFpvg/Se1CP802RItKYFPfSLRxJ3jf0bVI9hvYOEktPAYW2nd7S8MBcyHYyacHK bISqSiTmDzG+ivnR+SZJv3USNTYVMz9rCQVSxdOcLlqsJauko79NnwQJbzDTyLoo Yolwz75qBOH2/xOMir peEqRJrF/EQjWekJmGk9RtboXePu2rka+Xm51syBPhiXJAqOGfbfaFu9tNqs/e2Vjja/tE1M0lqvxfXQ6da6HrT hsm5id4CIZFliOacRfrsPLRixS/IQYtksxghvJwbqOsblsITail9Ayy4tKcogeEZiOO+4Ed264NSKmk713wKwJLA FjCFogBx8GE3OBz4pqcAn/ydA=
附 录 C
(资料性附录)
HMAC-MD5参数签名方式
C.1 HMAC-MD5 参数签名算法
HMAC(K,M)=H(K④opad|H(K④ipad|M))
其中： K 是密钥 (OperatorSecret), 长度可为64字节，若小于该长度，在密钥后面用“0”补齐。
M是消息内容；
H是散列函数；
opad 和 ipad 分别是由若干个0x5c 和 0x36 组成的字符串；
④表示异或运算；
|表示连接操作。
C.2 HMAC-MD5 参数签名流程
a)在签名密钥 (SigSecret) 后面添加0来创建一个长为64字节的字符串 (str);
b)将上一步生成的字符串 (str)与 ipad(0x36) 做异或运算，形成结果字符串 (istr);
c)将消息内容data附加到第二步的结果字符串 (istr) 的末尾；
d)做 MD5 运算于第三步生成的数据流 (istr);
e)将第一步生成的字符串(str)与 opad(0x5c) 做异或运算，形成结果字符串(ostr);
f)再将第四步的结果 (istr) 附加到第五步的结果字符串(ostr)的末尾；
g)做MD5 运算于第六步生成的数据流 (ostr), 输出最终结果 (out)。
C.3 参数签名示例
示例签名密钥：
1234567890abcdef
示例运营商标识 (OperatorlD):
123456789
示例参数信息 (Data):
il7BOBSEjFdzpyKzfOFpvg/SelCP802RItKYFPfSLRxJ3jfObV¹9hvYOEktPAYW2nd7S8MBcyHYyacHK bISq5iTmDzG+ivnR+SZJv3USNTYVMz9rCQVSxd0cLlqsJauko79NnwQJbzDTyLooYolwz75qBOH2/xOMir peEqRJrF/EQjWekJmGk9RtboXePu2rka+Xm51syBPhiXJAq0GfbfaFu9tNqs/e2Vjja/ltE1M0lqvxfXQ6da6HrT hsm5id4CIZFliOacRfrsPLRixS/IQYtksxghvJwbqOsblsITail9Ayy4tKcogeEZiOO+4Ed264NSKmk713wKwJLA FjCFogBx8GE3OBz4pqcAn/ydA=
示例时间戳 (TimeStamp):
20160729142400
示例自增序列 (Seq):
0001
示例签名 (Sig):
745166E8C43C84D37FFECOF529C4136F
如果侵权请联系删除。