《电动汽车充换电服务信息交换》第四部分.docx
《《电动汽车充换电服务信息交换》第四部分.docx》由会员分享，可在线阅读，更多相关《《电动汽车充换电服务信息交换》第四部分.docx（15页珍藏版）》请在冰豆网上搜索。
《电动汽车充换电服务信息交换》第四部分
ICS35.240.60
L73
T/CEC
中国电力企业联合会标准
T/CECXXXXX—XXXX
/XXXXX—XXXX
电动汽车充换电服务信息交换
第4部分：
数据传输与安全
Chargingandbatterysdatainteractiveforelectricvehicle
Part4：
DataexchangeandSecurity
XXXX-XX-XX发布
XXXX-XX-XX实施
中国电力企业联合会标准
中国电力企业联合会标准
中国电力企业联合会标准
目 次
前 言
《电动汽车充换电服务信息交换》分为四个部分：
第1部分：
总则；
第2部分：
公共信息交换规范；
第3部分：
业务信息交换规范；
第4部分：
数据传输及安全；
本规范为第4部分。
本规范按照GB/T1.1-2009给出的规则编写。
请注意本规范中的某些内容可能涉及专利。
本规范的发布机构不承担识别这些专利的责任。
本规范由中国电力企业联合会提出。
本规范由能源行业电动汽车充电设施标准化技术委员会归口。
本规范主要起草单位：
本规范参加起草单位：
本规范主要起草人：
本标准为首次制定。
本标准在执行过程中的意见或建议反馈至中国电力企业联合会标准化中心（北京市白广路二条一号，100761）。
引 言
为加快电动汽车充电基础设施建设，促进不同充电服务平台互联互通，构建充电基础设施信息服务信息交换体系架构，统一信息接口通信协议，实现不同充电运营企业、不同区域的充电服务设施、第三方平台信息资源等互联和充分利用，实现充电设施网络服务平台间数据交换，充电系统服务功能跨平台信息交换服务，特制定本标准。
电动汽车充换电服务信息交换第4部分：
数据传输与安全
范围
本部分规定了电动汽车充换电服务信息交换的数据传输规范和安全要求，包含充换电服务信息交换的平台认证规范、数据传输规范和数据传输安全要求。
本部分适用于归属不同运营商的电动汽车充换电运营服务平台之间的充换电服务信息交换，以及电动汽车充换电运营服务平台与其他第三方服务及管理平台之间的信息交换。
规范性引用文件
下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件，仅所注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
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电动汽车术语
术语和定义
GB/T19596、GB/T29317、GB/Z19027-2005以及《电动汽车充换电服务信息交换第1部分：
总则》中定义的以及下列术语和定义适用于本文件。
数据传输体系
概述
数据传输体系要求了参与电动汽车充换电服务的各角色和实体之间应在正常、安全、有效的原则下通过规范的接口进行信息交换，相互协同地向电动汽车用户提供充换电服务。
相关实体及其之间的信息交换接口参见《电动汽车充换电服务信息交换第1部分：
总则》。
电动汽车充换电服务信息通过数据传输接口进行交换，数据传输接口众多，既存在于各个服务逻辑层之间，也存在于同一逻辑层的不同管理域之间，数据传输接口可通过身份认证、访问控制、数据加密、数字签名等安全措施，保障数据传输过程中要保障所传输数据的机密性和安全性。
数据传输一般流程
电动汽车充换电服务信息交换一般需要经过平台认证、数据请求和数据返回3个步骤。
电动汽车充换电服务信息交换流程
数据传输接口的基本要求
电动汽车充换电服务信息交换应根据国家信息安全等级保护相关要求。
运营商须提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息的存取控制、应用系统操作的安全等。
基本要求：
1）采用身份认证、访问控制、数据加密、数字签名等安全措施；
2）采用安全可靠并且普遍使用的加密算法；
3）密钥的存贮和交易信息的加密／解密需要在安全的环境中；
4）遵循数据安全保密的国家和行业标准；
5）定期更换密钥；
6）具备对报文做来源正确性鉴别的机制（HMAC）。
平台认证方式及规则
概述
电动汽车充换电服务信息交换应具备平台认证服务提供平台之间的鉴权认证功能。
平台之间在信息交换前，需完成平台认证，获得平台交换能力。
平台认证模式
平台认证支持分布式认证模式和中心交换认证模式。
分布式认证模式由运营商之间进行鉴权认证，运营商之间确定运营商标识（OperatorID）、运营商密钥（Operator_Secret）和消息密钥（Data_Secret），具体认证方式可由运营商协商确定。
中心交换认证模式由统一的认证服务方提供鉴权认证服务，运营商与中心认证服务方确定运营商标识（OperatorID）、运营商密钥（Operator_Secret）和消息密钥（Data_Secret），具体认证方式由各运营商和认证服务方共同确定。
分布式认证模式
中心交换认证模式
平台认证方法
平台认证宜采取身份认证和访问控制相结合的方式进行。
身份认证可采取用户名/口令认证、密钥认证或数字证书认证等方式进行；访问控制可采取IP访问控制、时间访问控制等多种手段结合。
用户身份认证成功后授予Token，每次向服务端请求资源的时候需要带着服务端签发的Token，服务端验证Token成功后，才返回请求的数据。
Token的有效期不宜大于7天，Token丢失或失效后需要再次发起认证服务。
平台认证方式
数据传输方式及规则
数据传输接口规则
所有数据传输接口均采用HTTP（S）接口，每个接口的URL均采用如下格式定义：
http（s）:
//[域名]/evcs/v[版本号]/[接口名称]
1）域名：
各接入运营商所属域名。
2）版本号：
代表接口版本号，不同的版本地址对应相应版本代码。
系统升级期间，新旧版本可同时存在，待所有接入方都切换到新接口，旧接口即可下线。
从而达到平滑升级的目的。
3）接口名称：
所请求/调用接口的名称，具体接口名称见《电动汽车充换电服务信息交换第2部分：
公共信息交换规范》和《电动汽车充换电服务信息交换第3部分：
业务信息交换规范》。
为保证各接口的功能明确清晰，每个URL只允许对应一种功能。
其中测试例分类:
接口调用方式
所有接口均使用HTTP（S）/POST方式传输参数，传输过程中应包含消息头和消息主体两部分。
消息头规范
消息头一般需包含内容类型，内容类型（Content-Type）字段用于标识请求中的消息主体的编码方式，本标准中所规范的信息交换内容均采用JSON的方式，参数信息采用utf-8编码，因此需要配置消息头中的Content-Type为application/json;charset=utf-8。
消息主体规范
消息主体的组成
消息主体是信息交换过程中的具体内容，一般由运营商标识（OperatorID）、凭证（Token）、参数内容（Data）、时间戳（TimeStamp）和数字签名（Sig）组成。
消息主体内容表
参数名
说明
举例
Token
业务执行的凭证
Data
各接口具体参数信息
Data:
{
[
‘stationID’:
充电站ID,
‘platformID’:
归属运营平台所有方ID,
xxxxxxxxx,
],
……
[
‘stationID’:
充电站ID,
‘platformID’:
归属运营平台所有方ID,
xxxxxxxxx,
]
}
TimeStamp
时间戳
接口请求时时间戳信息,格式为yyyyMMddHHmmss
Sig
参数签名
参数签名规则
参数签名采用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）。
参数传递要求
参数传递过程中的所有参数都要先进行urlencode转义，然后再按照key=value格式使用&连接在一起。
批量数据传输
数据传输接口中的Data字段可为数组型的JSON格式，数据发送方可通过该字段实现批量数据的传输。
返回参数规则
数据传输接口的返回参数包括两个部分：
ret,msg。
1）ret:
必填字段，返回编码参考下表。
2）msg:
可选字段，当ret!
=0是存在，表示具体错误信息。
3）采用utf-8编码，JSON格式。
4）举例：
｛
‘ret’:
401,
‘msg’:
‘Invalidsignature’,｝
返回参数编码表
Ret值
说明
-1
系统繁忙，此时请求方稍后重试
0
请求成功
401
签名错误
402
Token错误
403
POST参数不合法,缺少必须的示例：
OperatorID,sig,TimeStamp,Data四个参数
404
请求的业务参数不合法，各接口定义自己的必须参数
500
系统错误
密钥的使用及管理
各运营商系统间在消息传递时，需要保障传输和接收数据的安全和完整。
基本安全要求
运营商必须满足数据安全传输控制方面的要求。
运营商必须提供严格的系统安全保密机制，保障信息交换接口安全、稳定、可靠地运行，包括信息的存取控制、应用系统操作的安全等。
密钥的安全要求
密码算法用于密钥的产生、分发、HMAC以及加密等安全功能，相关的算法模块在其生命周期内不能被修改、导出至安全环境外部。
指定功能的密钥仅能做指定功能使用，不能被其他任何功能使用。
密钥的产生
数据密钥应具备随机产生特性，密钥产生后要检查密钥的有效性，弱密钥和半弱密钥需被剔除。
运营商加入信息交换时，必须申请独立的密钥文件，密钥可由运营商协商产生。
密钥的分发
密钥的分发应该由安全方式进行，可通过联机报文或数字信封的方式加密传输。
密钥的存储
密钥宜保存在硬件加密机内。
如果出现在硬件加密机外，则必须密文方式出现。
密钥注入、密钥管理和密钥档案的保管应由专人负责。
使用密钥和销毁密钥要在监督下进行并应有使用、销毁记录。
密钥的销毁
当新密钥产生后，生命期结束的旧密钥必须从数据库和内存中清除，防止被替换使用；同时所有可能重新构造此密钥的信息也必须清除。
新密钥成功启用和旧密钥自动销毁的记录将被更新。
数据的加密处理
每个运营商交互前需要分配运营商标识（OperatorID）、运营商密钥（Operator_Secret）和消息密钥（Data_Secret）。
1）运营商标识（OperatorID）:
固定9位，运营商的组织机构代码，作为运营商的唯一标示。
2）运营商密钥（Operator_Secret）:
可采用32H、48H和64H，由0-F字符组成，为签名的加密密钥。
3）消息密钥（Data_Secret）:
用于对所有接口中Data信息进行加密。
数据加密规则
消息发送方需要对Data字段中涉及交易及隐私等数据利用消息密钥（Data_Secret）进行加密，加密算法宜使用AES加密。
消息接收方收到消息之后，根据消息密钥（Data_Secret）对消息体中的Data数据进行解密，校验参数合法性等后续业务处理。
数据加/解密方法
数据传输的加密使用对称加密算法AES加密，AES算法的密钥长度、分组长度和轮数的关系如表3所示。
Key-Block-Round关系
密钥长度
（Nkwords）
分组长度
（Nbwords）
轮数
（Nr）
4
4
10
6
4
12
8
4
14
对于AES加密和解密变换，AES算法使用的轮函数由4个不同的以字节为基本单位的变换复合而成，该过程由四个不同的阶段组成：
1）S盒变换，用一个S盒完成分组中的按字节代替；
2）行移位变换，一个简单的置换；
3）列混淆变换，一个利用在域GF（28）上的算术性的代替；
4）轮密钥加变换，一个利用当前分组和扩展密钥的一个部分进行按位异或。
AES对数据的加密过程是通过把输入的明文和密钥由轮函数经Nr轮迭代来实现的，结尾轮与前Nr-1轮不同。
前Nr-1轮依次进行S盒变换、行移位变换、列混淆变换和轮密钥加变换；结尾轮与前Nr-1轮相比去掉了列混淆变换。
而解密过程与加密过程相反，通过把输入的密文和密钥由轮函数经Nr轮迭代来实现的，结尾轮与前Nr-1轮不同。
前Nr-1轮依次进行逆行移位变换、逆S盒变换、轮密钥加变换和逆列混淆变换；结尾轮与前Nr-1轮相比去掉了逆列混淆变换。
AES算法的加密解密过程如图5所示。
AES加/解密过程图
数据加/解密示例
密钥：
1234567890abcdef
明文信息：
{"total":
1,"stationStatusInfo":
{"operationID":
"123456789","stationID":
"111111111111111","connectorStatusInfos":
{"connectorID":
1,"equipmentID":
"1","status":
4,"currentA":
0,"currentB":
0,"currentC":
0,"voltageA":
0,"voltageB":
0,"voltageC":
0,"soc":
10,}
秘文：
DHVWF+8xRIfU7nUCNQdLaGF15VaMZWtNcwaqeumUPe/ok9zgSkR0pbOJUmYYQs7ZFMN7GhLB1ywEN3kb1gH4z+Mc2Z4rQe8Xa42LrmkDRvwwosmVMuR+mbLFCG+Xf5unkRO6JJx1PiTAxAB6oyWqUmbOKskK81LqpWBU5fKnBZwXo3jv2hnKItwCODYw+B+Pg+0IzZ5ye5cKcwz99NO5//H2gU0scZhn+rl8Jcktbm42TVklnxdzG/aw200H2z9ugpB1q2X0sGAi55SQH3DbLpWb5oQE5vy0As7lje4e+4dE8vbLIR0dMw8/lA9cBPYRO2WOkH6SFwFUyi+IishP8j+mzEcfoyAOIUSh5G/5VYqlYu1zlVUsYCHWu7MTE1Gr55SicHZQxl5KHgmgFBw8OQl8DerA++D8vswR8eiRNcXR2MQmNXYarCmZ7Kuc6mRSbrSk2cImOZAywVIo6MpBSu/u0BINysS3S7Ni1LB6zqAu3Ly0yNbbxzz+ZpHjmAM+MMsx4/K6LtG1rhiW8iE3bbGOLJqu9njLFVLQtKXrVsUnF4b1FWuIADG3FBCXqcdyTTTj5vNwI2xxFm/zq5lvJUKUlcFPvYSwBQFsjKHZnl8=
（资料性附录）
数字信封密钥分发方式
数字信封的定义
数字信封是公钥密码体制在实际中的一个应用，是用加密技术来保证只有规定的特定收信人才能阅读通信的内容。
数字信封的原理
在数字信封中，信息发送方采用对称密钥来加密信息内容，然后将此对称密钥用接收方的公开密钥来加密（这部分称数字信封）之后，将它和加密后的信息一起发送给接收方，接收方先用相应的私有密钥打开数字信封，得到对称密钥，然后使用对称密钥解开加密信息，这种技术的安全性相当高。
数字信封主要包括数字信封打包和数字信封拆解，数字信封打包是使用对方的公钥将加密密钥进行加密的过程，只有对方的私钥才能将加密后的数据（通信密钥）还原；数字信封拆解是使用私钥将加密过的数据解密的过程。
密钥的更换
数字信封的功能类似于普通信封，普通信封在法律的约束下保证只有收信人才能阅读信的内容；数字信封则采用密码技术保证了只有规定的接收人才能阅读信息的内容。
数字信封中采用了对称密码体制和公钥密码体制。
信息发送者首先利用随机产生的对称密码加密信息，再利用接收方的公钥加密对称密码，被公钥加密后的对称密码被称之为数字信封。
在传递信息时，信息接收方若要解密信息，必须先用自己的私钥解密数字信封，得到对称密码，才能利用对称密码解密所得到的信息。
这样就保证了数据传输的真实性和完整性。
_________________________________
升级会员 