《电动汽车充换电服务信息交换》第四部分.docx
《《电动汽车充换电服务信息交换》第四部分.docx》由会员分享，可在线阅读，更多相关《《电动汽车充换电服务信息交换》第四部分.docx（14页珍藏版）》请在冰豆网上搜索。
《电动汽车充换电服务信息交换》第四部分
《电动汽车充换电服务信息交换》第四部分
前 言
《电动汽车充换电服务信息交换》分为四个部分：
1——第1部分：
总则；
2——第2部分：
公共信息交换规范；
3——第3部分：
业务信息交换规范；
4——第4部分：
数据传输及安全；
本规范为第4部分。
本规范按照GB/T1.1-2009给出的规则编写。
请注意本规范中的某些内容可能涉及专利。
本规范的发布机构不承担识别这些专利的责任。
本规范由中国电力企业联合会提出。
本规范由能源行业电动汽车充电设施标准化技术委员会归口。
本规范主要起草单位：
本规范参加起草单位：
本规范主要起草人：
本标准为首次制定。
本标准在执行过程中的意见或建议反馈至中国电力企业联合会标准化中心（北京市白广路二条一号，100761）。
引 言
为加快电动汽车充电基础设施建设，促进不同充电服务平台互联互通，构建充电基础设施信息服务信息交换体系架构，统一信息接口通信协议，实现不同充电运营企业、不同区域的充电服务设施、第三方平台信息资源等互联和充分利用，实现充电设施网络服务平台间数据交换，充电系统服务功能跨平台信息交换服务，特制定本标准。
电动汽车充换电服务信息交换第4部分：
数据传输与安全
1 范围
本部分规定了电动汽车充换电服务信息交换的数据传输规范和安全要求，包含充换电服务信息交换的平台认证规范、数据传输规范和数据传输安全要求。
本部分适用于归属不同运营商的电动汽车充换电运营服务平台之间的充换电服务信息交换，以及电动汽车充换电运营服务平台与其他第三方服务及管理平台之间的信息交换。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件，仅所注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T19596-2004：
电动汽车术语
GB/T29317-2012：
电动汽车充换电设施术语
GB/T2260-2007中华人民共和国行政区域代码
GB11714-1997全国组织机构代码编制规则
GB/T31286-2014全国组织机构代码与名称
GB/T18391.1-2002信息技术数据元的规范与标准化第1部分：
数据元的规范与标准化框架
GB/T9387.1-1998信息技术开放系统互联基本参考模型第1部分：
基本模型
GB/T7408-2005数据元和交换格式信息交换日期和时间表示法
GB/T22239-2008信息安全技术信息系统安全等级保护基本要求
GB/T25070-2010信息安全技术信息系统等级保护安全设计技术要求
GB/T20271-2006信息安全技术信息系统安全通用技术要求
GB/T20988-2007信息安全技术信息系统灾难恢复规范
GB/T19596-2004电动汽车术语
3 术语和定义
GB/T19596、GB/T29317、GB/Z19027-2005以及《电动汽车充换电服务信息交换第1部分：
总则》中定义的以及下列术语和定义适用于本文件。
4 数据传输体系
4.1 概述
数据传输体系要求了参与电动汽车充换电服务的各角色和实体之间应在正常、安全、有效的原则下通过规范的接口进行信息交换，相互协同地向电动汽车用户提供充换电服务。
相关实体及其之间的信息交换接口参见《电动汽车充换电服务信息交换第1部分：
总则》。
电动汽车充换电服务信息通过数据传输接口进行交换，数据传输接口众多，既存在于各个服务逻辑层之间，也存在于同一逻辑层的不同管理域之间，数据传输接口可通过身份认证、访问控制、数据加密、数字签名等安全措施，保障数据传输过程中要保障所传输数据的机密性和安全性。
4.2 数据传输一般流程
电动汽车充换电服务信息交换一般需要经过平台认证、数据请求和数据返回3个步骤。
图1 电动汽车充换电服务信息交换流程
4.3 数据传输接口的基本要求
电动汽车充换电服务信息交换应根据国家信息安全等级保护相关要求。
运营商须提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息的存取控制、应用系统操作的安全等。
基本要求：
1）采用身份认证、访问控制、数据加密、数字签名等安全措施；
2）采用安全可靠并且普遍使用的加密算法；
3）密钥的存贮和交易信息的加密／解密需要在安全的环境中；
4）遵循数据安全保密的国家和行业标准；
5）定期更换密钥；
6）具备对报文做来源正确性鉴别的机制（HMAC）。
5 平台认证方式及规则
5.1 概述
电动汽车充换电服务信息交换应具备平台认证服务提供平台之间的鉴权认证功能。
平台之间在信息交换前，需完成平台认证，获得平台交换能力。
5.2 平台认证模式
平台认证支持分布式认证模式和中心交换认证模式。
分布式认证模式由运营商之间进行鉴权认证，运营商之间确定运营商标识（OperatorID）、运营商密钥（Operator_Secret）和消息密钥（Data_Secret），具体认证方式可由运营商协商确定。
中心交换认证模式由统一的认证服务方提供鉴权认证服务，运营商与中心认证服务方确定运营商标识（OperatorID）、运营商密钥（Operator_Secret）和消息密钥（Data_Secret），具体认证方式由各运营商和认证服务方共同确定。
图2 分布式认证模式
图3 中心交换认证模式
5.3 平台认证方法
平台认证宜采取身份认证和访问控制相结合的方式进行。
身份认证可采取用户名/口令认证、密钥认证或数字证书认证等方式进行；访问控制可采取IP访问控制、时间访问控制等多种手段结合。
用户身份认证成功后授予Token，每次向服务端请求资源的时候需要带着服务端签发的Token，服务端验证Token成功后，才返回请求的数据。
Token的有效期不宜大于7天，Token丢失或失效后需要再次发起认证服务。
图4 平台认证方式
6 数据传输方式及规则
6.1 数据传输接口规则
所有数据传输接口均采用HTTP（S）接口，每个接口的URL均采用如下格式定义：
http（s）:
//[域名]/evcs/v[版本号]/[接口名称]
1）域名：
各接入运营商所属域名。
2）版本号：
代表接口版本号，不同的版本地址对应相应版本代码。
系统升级期间，新旧版本可同时存在，待所有接入方都切换到新接口，旧接口即可下线。
从而达到平滑升级的目的。
3）接口名称：
所请求/调用接口的名称，具体接口名称见《电动汽车充换电服务信息交换第2部分：
公共信息交换规范》和《电动汽车充换电服务信息交换第3部分：
业务信息交换规范》。
为保证各接口的功能明确清晰，每个URL只允许对应一种功能。
其中测试例分类:
6.2 接口调用方式
所有接口均使用HTTP（S）/POST方式传输参数，传输过程中应包含消息头和消息主体两部分。
6.3 消息头规范
消息头一般需包含内容类型，内容类型（Content-Type）字段用于标识请求中的消息主体的编码方式，本标准中所规范的信息交换内容均采用JSON的方式，参数信息采用utf-8编码，因此需要配置消息头中的Content-Type为application/json;charset=utf-8。
6.4 消息主体规范
6.4.1 消息主体的组成
消息主体是信息交换过程中的具体内容，一般由运营商标识（OperatorID）、凭证（Token）、参数内容（Data）、时间戳（TimeStamp）和数字签名（Sig）组成。
表1 消息主体内容表
参数名
说明
举例
Token
业务执行的凭证
Data
各接口具体参数信息
Data:
{
[
‘stationID’:
充电站ID,
‘platformID’:
归属运营平台所有方ID,
xxxxxxxxx,
],
……
[
‘stationID’:
充电站ID,
‘platformID’:
归属运营平台所有方ID,
xxxxxxxxx,
]
}
TimeStamp
时间戳
接口请求时时间戳信息,格式为yyyyMMddHHmmss
Sig
参数签名
6.4.2 参数签名规则
参数签名采用HMAC-MD5算法，采用MD5作为散列函数，通过密钥（Operator_Secret）对整个消息主体进行加密，然后采用Md5信息摘要的方式形成新的密文。
（1）HMAC-MD5算法
HMAC（K，M）=H（K⊕opad∣H（K⊕ipad∣M））
其中:
K是密钥（Operator_Secret），长度可为64字节，若小于该长度，在密钥后面用“0”补齐。
M是消息内容；
H是散列函数；
opad和Ipad分别是由若干个0x5c和0x36组成的字符串；
⊕表示异或运算；
∣表示连接操作。
（2）HMAC-MD5流程
1）在密钥（Operator_Secret）后面添加0来创建一个长为64字节的字符串（str）；
2）将上一步生成的字符串（str）与ipad（0x36）做异或运算，形成结果字符串（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字段可为数组型的JSON格式，数据发送方可通过该字段实现批量数据的传输。
6.6 返回参数规则
数据传输接口的返回参数包括两个部分：
ret,msg。
1）ret:
必填字段，返回编码参考下表。
2）msg:
可选字段，当ret!
=0是存在，表示具体错误信息。
3）采用utf-8编码，JSON格式。
4）举例：
｛
‘ret’:
401,
‘msg’:
‘Invalidsignature’,｝
表2 返回参数编码表
Ret值
说明
-1
系统繁忙，此时请求方稍后重试
0
请求成功
401
签名错误
402
Token错误
403
POST参数不合法,缺少必须的示例：
OperatorID,sig,TimeStamp,Data四个参数
404
请求的业务参数不合法，各接口定义自己的必须参数
500
系统错误
7 密钥的使用及管理
各运营商系统间在消息传递时，需要保障传输和接收数据的安全和完整。
7.1 基本安全要求
运营商必须满足数据安全传输控制方面的要求。
运营商必须提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息的存取控制、应用系统操作的安全等。
7.2 密钥的安全要求
密码算法用于密钥的产生、分发、HMAC以及加密等安全功能，相关的算法模块在其生命周期内不能被修改、导出至安全环境外部。
指定功能的密钥仅能做指定功能使用，不能被其他任何功能使用。
7.2.1 密钥的产生
数据密钥应具备随机产生特性，密钥产生后要检查密钥的有效性，弱密钥和半弱密钥需被剔除。
运营商加入信息交换时，必须申请独立的密钥文件，密钥可由运营商协商产生。
7.2.2 密钥的分发
密钥的分发应该由安全方式进行，可通过联机报文或数字信封的方式加密传输。
7.2.3 密钥的存储
密钥宜保存在硬件加密机
升级会员 