报文传输格式及加密规范文档格式.docx

报文传输格式及加密规范文档格式.docx

《报文传输格式及加密规范文档格式.docx》由会员分享，可在线阅读，更多相关《报文传输格式及加密规范文档格式.docx（28页珍藏版）》请在冰豆网上搜索。

5、后续流程参见“1.1.2修改密钥节”描述。

1.2.2密钥交换

交换加密密钥由下级节点发起，基本流程如下：

1、下级节点安全管理人员登录管理界面；

2、安全管理人员运行【修改加密密钥】功能，系统检查目前密钥修改状态。

如newMKey=NULL，则说明无待回应的申请报文，此时安全管理人员可以输入当前密码（curMKeyStr）和新密码（newMKeyStr），并确认；

如newMKey非NULL，则说明存在待回应的申请报文，此时禁止安全管理人员输入当前密码（curMKeyStr）和新密码（newMKeyStr），但可以再次提交修改密钥申请报文，系统自动使用存储的curMKey和newMKey发出修改密钥申请报文；

3、下级节点使用密钥生成算法计算curMKeyStr和newMKeyStr生成对应的curMKey和newMKey，检查生成的curMKey和存储的curMKey是否一致；

如不相符，提示安全管理人员当前密钥错误，返回2重新输入；

如相符，则使用curMKey加密申请报文并发送给上级节点，存储newMKey；

4、上级节点接收并解密该申请报文。

如报文curMKey=存储的curMKey，则使用存储curMKey覆盖存储preMKey，使用报文newMKey覆盖存储curMKey，返回成功回应报文给下级节点；

如报文curMKey=存储preMKey，则使用报文newMKey覆盖存储curMKey，返回成功回应报文给下级节点；

否则，返回当前密钥不符拒绝回应报文给下级节点。

（成功回应报文使用报文curMKey加密；

拒绝回应报文使用通用回应报文，明文传输；

无法解密的报文，返回“报文无法解密”通用回应报文，明文传输）

5、下级节点接收并解密回应报文；

是成功回应且回应报文newMKey＝存储newMKey，则使用存储curKey覆盖存储preKey，使用存储newKey覆盖存储curKey，使用NULL值覆盖newKey；

否则丢弃该回应报文。

1.2.3异常适应性分析

密钥交换过程发生异常，可能导致下级节点与上级节点的密钥不符，从而导致业务报文无法解密，系统提供的密钥交换方案应防止该情况的出现。

密钥交换过程可能出现的异常是丢失申请报文或丢失回应报文。

为避免丢失报文时出现“密钥修改中”的悬决状态，密钥交换过程允许在前次申请报文没有回应的情况下，再次提交新的申请报文以自动弥补申请报文或回应报文丢失的情况，此做法同时可能带来报文乱序的异常情况。

下面分析上述密钥修改方案的异常适应性。

1.2.3.1丢失申请报文

下级节点提交申请报文，而上级节点没有收到该申请报文的异常情况，称为丢失申请报文。

此时上级节点和下级节点均没有修改密钥，因此下级节点再次提交申请报文恢复丢失的申请报文。

1.2.3.2丢失回应报文

下级节点提交申请报文，上级节点已处理该申请报文，但下级节点没有收到上级节点回应报文的异常情况，称为丢失回应报文。

根据丢失回应报文的类型，分为两种情况：

一是丢失拒绝回应报文；

二是丢失成功回应报文。

丢失拒绝回应时，上级节点和下级节点均没有修改密钥，因此下级节点可以再次提交申请报文。

丢失成功回应时，上级节点已经完成更新preKey=curKey，curKey＝newKey，而下级节点没有相应地更新，出现上下级密钥不符的情况。

此时，下级节点新发送的业务使用curKey加密，上级节点使用curKey解密失败，使用preKey解密成功，对往账业务没有影响；

上级节点新发送的业务使用newKey加密，下级节点使用curKey解密失败，使用newKey解密成功，对来帐业务没有影响。

这说明丢失成功回应对业务没有影响。

由于没有回应报文，下级节点可以多次提交申请报文；

由于新申请报文和原申请报文完全相同，因此对上级节点没有影响，而下级节点收到任何一个成功回应报文，即可完成密钥的变更动作。

1.2.3.3重复提交申请及乱序

如前次申请报文没有回应时，下级节点只能重发与前次相同的回应报文，无论上级节点是否曾处理过该申请报文，重复的申请报文均能被上级节点正确处理并返回成功回应。

第一个成功回应报文到达下级节点后，下级节点进行相应的密钥变更处理。

后续重复的成功回应报文因newMKey比较失败而被自动丢弃。

因此多次提交相同的申请报文对上下级均无影响。

（相同内容的报文及其回应报文先后顺序无所谓，因此不存在乱序的问题）

如前次申请回应成功后，下级节点即刻提交与前次申请内容不同的申请报文，此时可能出现多个新、旧申请报文以及多个新、旧报文的回应报文在途的情况。

如申请报文没有发生乱序，则旧申请报文在上级节点可以正常处理，且回应成功回应报文；

而该成功回应报文到达下级节点时，因newMKey比较失败而被自动丢弃。

如回应报文没有发生乱序，旧申请报文的回应报文到达下级节点，因比较newMKey失败而被丢弃。

如申请报文发生乱序，则新申请报文先于旧申请报文到达上级节点，上级节点按新申请报文进行变更后，旧申请报文再到达上级节点时，因curMKey比较失败被上级节点拒绝。

如回应报文发生乱序，新申请报文的回应报文到达下级节点后，下级节点进行了相应地密钥变更，则旧申请报文的回应报文再到达下级节点时，因比较newMKey失败而被丢弃。

综上分析，密钥修改流程可以适应异常情况。

1.3报文加密

报文传输加密使用参考数字信封加密模式，基本做法如下：

1、生成随机密码（wrkKeyStr）；

2、根据密钥生成算法计算wrkKeyStr生成工作密钥（wrkKey）；

3、使用wrkKey加密明文报文数据（msg）得到Emsg；

4、使用存储的curMKey加密KEY:

wrkKey得到Ewk；

5、计算msg的MD5值作为原文校验Cmsg；

6、组织Ewk+Emsg+Cmsg为通信报文发送给接收方。

1.4报文解密

接收方收到通信报文后，按下列流程解密报文：

1、按通信报文格式分割Ewk、Emsg、Cmsg；

2、使用存储的curMKey、preMKey、newMKey尝试解密Ewrkstr得到解密结果；

如解密结果的前四字符为KEY:

则说明解密成功，否则解密失败；

如解密失败，返回拒绝回应报文；

如解密成功，从解密结果中分类wrkKey；

3、使用wrkKey解密Emsg得到msg；

4、计算msg的MD5值与Cmsg比较，检查报文校验。

2报文交换格式

ECDS使用XML报文传输业务数据。

该XML报文仅承载业务数据本身，并没有包含与报文流转、交换、路由等相关的通信级信息。

这些通信级信息须附加到额外的数据块中传输。

为处理的简便性，ECDS将通信级数据块附加到业务报文的头部，称之为报头，而将业务报文本身称为报体。

报头与报体构成一个完成的报文，即ECDS报文格式如下：

MSGHEADER

MSGBODY

2.1报头格式

报头分为两类，一类供节点间网关系统间使用，一类供节点内部业务系统和网关系统间使用。

2.1.1节点间报头格式说明

节点间报头传输通信级数据，主要由版本标识、发起方、接收方、报文描述四个部分组成，总长度为200字节，格式如下：

域

类

域名

含义

位

置

长

度

类型

属

性

说明

BeginFlag

起始标识

3

x

M

标识报头块结束，固定使用：

{H:

版本

VersionID

版本号

2

n

标识报头格式的版本号，范围为01－99；

目前为第1版，即值为01；

发

起

方

SenderID

发送节点号

5

12

标识相邻节点的发起方；

使用支付系统行号；

0000NPC；

nnnnCCPC；

nnnnnnnnnnnn直接参与者；

SenderSID

发送系统号

17

标识发出本报文的应用系统；

对电子商业汇票系统，固定为CD；

SenderCID

发送计算机号

19

8

O

标识发起方发出本报文的计算机编号，由发起方自行编制，在本节点应唯一；

指定本域，则本报文的通信级回应报文优选回应给本机器，否则回应给发起方任何活动的机器；

对电子商业汇票系统，可以填全空格，即不指定计算机；

接

收

ReceiverID

接收节点号

27

标识相邻节点的接收方；

0000NPC

nnnnCCPC

nnnnnnnnnnnn直接参与者

ReceiverSID

接收系统号

39

ReceiverCID

接收计算机号

41

标识接收方接收本报文的目标计算机，由发起方指定；

如果本域没有指定，则由接收方网关自行选择目标计算机；

报文描述

OrigSender

报文发起人

49

标识报文原始发起方；

OrigReceiver

报文接收人

61

标识报文最终接收方；

OrigSendDate

报文发起日期

73

d

标识OrigSender发出本报文的机器日期；

OrigSendTime

报文发起时间

81

6

t

标识OrigSender发出本报文的机器时间；

MesgType

报文类型

87

20

标识报体承载的业务报文类型；

MesgID

报文标识号

107

通信层标识一个报文，由OrigSender顺序编制，并确保在OrigSendDate当日唯一；

接收方根据OrigSender＋OrigSendDate＋MesgID唯一确定一个报文，该三项重复的报文作为通信级重复报文；

MesgRefID

报文参考号

127

标识本报文的关联报文，由OrigSender设置，后续节点应保持该域不变，并在通信回应报文中带回该值，以便OrigSender匹配原报文；

MesgPriority

报文优先级

147

1

标识本报文的优先级；

1特级；

2紧急；

3普通；

对电子商业汇票系统，固定填写3;

EncryptFlag

报文加密标识

148

标识报体的加密算法；

Ｎ明文传输；

Ａ　AES加密传输；

Ｄ　DES加密；

Ｔ　3DES加密；

BodyLength

报体长度

149

标识本报文报体部分的长度；

对加密报文，本域为加密并转码后的报体长度；

BodyChksum

报体校验值

157

32

标识本报文报体部分的校验值，校验算法使用MD5；

对加密报文，本域为加密并转码后的报体校验值；

Reserve

（保留域）

189

保留。

EndFlag

结束标识

197

}\r\n

\r=0x0d

\n=0x0a

说明：

1、x类型标识字符，取值范围为a-z、A-Z、0-9、－（连字符）、_（下划线）；

n类型标识数字，取值范围为0-9；

d类型标识日期，格式为：

yyyymmdd；

t类型标识时间，格式为：

hhmmss；

2、各域均为定长域，值不足长度时应补位：

x类型的，后补空格（0x20）；

n类型的，前补0（0x30）；

3、报文流经各节点时应重新设置相邻发起节、相邻发起节点各域值；

4、强制域必须填值。

x类型的不能为全空格（0x20），n、d、t类型的不能是全0（0x30）；

可选项可以不填值，但应填充占位字符。

x类型填充空格（0x20），n、d、t类型的填充0（0x30）；

5、报头块各域字母均不区分大小写，建议使用全大写字母。

2.1.2填写范例

2.1.2.1行内系统提交给MBFE

01

102100012345

CD

（8个空格或发出报文的机器号）

（12个空格）

（8个空格）

=SenderID=102100012345

313584054321

20090225

094508

ECDS00100101

A1234B1234C1234D1234

X1234X1234X1234X1234

N

00006447

A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4

*注：

MBFE暂不支持集群，因此发起方、接收方计算机号不填。

2.1.2.2MBFE转发给CCPC

1000

D

00074835

3D4E5F6A1A1B2CB5F2C3D4E6A1B2C3D4

2.1.2.3CCPC转发给NPC

BJCD0101

0000

A

00894835

A1C3DA1B2C4E6AB53D4E5F6F21B2C3D4

CCPC与NPC间可能启用集群功能，因此需要修改报头发起、接收方；

而且，CCPC须变更加密算法，因此报头中报体相关各域需要重新设置。

2.1.2.4NPC转发给接收CCPC

NPCCD001

5840

报