污染物在线监控系统数据传输标准与数据传输安全研究

胡海涛

(攀枝花市环境信息中心，四川 攀枝花 617000)

1 前 言

为贯彻《中华人民共和国环境保护法》，指导污染源在线自动监控(监测)系统的建设，规范数据传输，保证各种环境监控监测仪器、传输网络和环保部门应用软件系统之间的连通，原国家环境保护总局于2005年12月30日发布了《污染源在线自动监控(监测)系统数据传输标准》(HJ/T212-2005)。

2017年5月1日，原环境保护部发布了《污染物在线监控(监测)系统数据传输标准》(HJ212-2017)，代替HJ/T212-2005。以下简称“212协议”。

本文通过对比两个版本的“212协议”，分析协议的区别和变化，并通过分析总结，结合污染源在线监控工作的经验，提出我所发现的数据传输安全问题，并提出可能的解决方法。

2 “212协议”新版协议带来的变化

“212协议”2017版和2005版相比较，页码从31页增加到61页，涉及到修订的内容包括协议层次、通讯协议、在线监控监测仪器仪表与数采仪的通讯方式3个大项，通讯协议修订内容最多，包括通讯协议结构、数据段结构、数据字段(新增10个、修改1个、去除15个)、系统编码(新增7个)、执行结果(新增4个)、请求命令(7个)、命令编码(新增17个、减少11个)9个小项[1-2]。

2.1 删除自动监控设备模拟输出接口

删除了自动监控设备与数据采集传输仪之间的模拟接口。在实际工作中，自动监控设备监测出的数据通过模拟接口传输到数据采集仪器上会产生误差，目前我市的在线传输设备与数据采集传输仪器的通讯基本使用了数字接口。

2.2 删除了非TCP/IP协议传输方式

在2017版本协议中取消了基于非TCP/IP协议的传输方式，如公共电话交换网和短消息通信，由于传输速率和实时性差等缺点的存在，在网络通讯技术高速发展的今天，已经很少有采用此种通讯方式进行通讯的。

2.3 增加了7个通信介质

“212协议”是构建在TCP/IP协议上，从2005年第一版发布，到2017年修订的第二版，期间多种通信介质应用于日常工作、生活中，此次修订也将这些通信介质纳入到标准中。包括：宽频分码多重存取(WCDMA)、时分同步CDMA、宽带CDMA(CDMA2000)、电力线通讯(PLC)、分时长期演进(TD-LTE)、微波存取全球互通(WiMAX)。

2.4 修改部分数据段长度错误

2017版的协议中，修正了部分数据段的长度数值计算规则，使全部数据段的长度值计算规则统一了。即数据段的长度应包含名称以及“=”符号。在2005版协议中总包数PNUM、包号PNO、访问密码、设备唯一标识、拆分包及应答标志5个数据段的长度不包含名称以及“=”符号。比如，请求编号PNUM定义长度是4位，这4位是不包含“PNUM=”字符的，在2017版中予以了修正。如图1。

图1 新版协议对数据段结构长度值修正示意图Fig.1 Schematic diagram of data segment structure length correction in the new version of protocol

2.5 字段变化

2.5.1 新增10个字段(表1)

表1 新增字段表Tab.1 New field tabl

新增加的字段补充了污染治理设施的参数(RestartTime、NewPW)，增加了现场端采样的相关参数(MinIterval、xxxxxx-SampleTime、VaseNO、CstartTIme、Stime)，为实际工作中现场端取样提供了标准。

2.5.2 修改1个字段

修改了SBxxx-RS字段。SBxxx-RS是污染治理设施运行状态的实时采样值，增加了校准、维护、报警、反吹状态值。

2.5.3 去除15个字段

去除了QN请求编号，xxx-Ala污染物报警期间内采样值、xxx-UpValue污染物报警上限值、xxx-Lowvalue污染物报警下限值、AlarmTime超标开始时间、AlarmType报警时间类型、ReportTarget上位机地址标识、ReportTime数据上报时间信息、DayStdValue噪声白天报警上限值、NightStdValue噪声夜晚报警上限值、Flag通讯标志、PNO包序号、PNUM总包号、PW访问密码、WarnTime超限报警时间。

去除的字段大多和报警参数有关，数据传输到上位机以后，上位机可自行根据报警值进行分析，无需从现场机传输此状态。另外PNO、PNUM、PW 3个字段在通讯包的数据段中已有定义，无需在数据区中再次定义。

2.6 系统编码表

2.6.1 新增7个监测类别编码

新增7个监测类别，如下：地下水质量监测，编码24;土壤质量监测，编码25;海水质量监测，编号26;挥发性有机物监测，编号27；工地扬尘污染源，编号39；烟气排放过程监控，编号51；污水排放过程监控，编号52。

2.6.2 新增4个执行结果编码

丰富了执行结果，2005版协议中，只有执行成功和执行失败，本次修订新增了命令请求条件错误，编号3；通讯超时，编号4；系统繁忙不能执行，编号5；系统故障，编号6。

2.6.3 新增7个请求返回编码

新增7个请求返回编码，告知6种错误状态，和一个未知的错误状态(表2)。

表2 新增请求命令返回表Tab.2 New request command return table

2.7 命令列表

2.7.1 新增命令

新增了现场机状态、采样、标识等命令(表3)。

表3 新增命令编码表Tab.3 New command code table

2.7.2 减少命令

减少了报警、上位机地址相关的命令(表4)。

表4 减少命令编码表Tab.4 Reduce command code table

2.8 增加在线监控(监测)仪器仪表与数采仪的通讯方式

2017版本加强对在线监控(监测)仪器的管理，明确接口采用RS-485接口，协议采用Modbus RTU协议。

3 污染源自动监控工作中存在的问题

通过研究，我发现了“212协议”存在的如下隐患。

3.1 数据传输过程中存在被窃听的隐患

“212协议”工作在TCP/IP的应用层，是明文传输的，存在被窃听的在可能，可以在网络数据传输、交换的过程中侦听窃取数据。如此会造成数据的泄露，影响数据安全。

下面通过一个实验来验证侦听数据的可能性。

为了能直观的看到窃听效果，简化实验，直接在通讯服务器上监听用于接收数据的端口。

实验环境：windows server 2012

实验工具：Visual studio 2017

实验方法：编写C# Winform程序，监听服务器本地连接的5003端口，看是否可能获取到传输的污染源自动监控数据。

实验介绍：使用Socket套件字异步通讯，获取所有通过的数据包。以下是主要实现代码片段：

新建一个Socket，使用SocketType.Raw，raw socket是原始套接字，工作在网络层或数据链路层。使用raw socket进行数据监听，在交换式网络中能接收到发向自己的包和以广播方式发的包。

Socket.BeginReceive是用于客户端和服务器端异步通讯，byteData数组用于接受数据的。AsyncCallBack委托是为接受数据后的回调函数。调用BeginReceive的时候，系统会开启一个独立的线程，用以执行回调函数及，直到EndReceive从socket的缓冲区中读到数据。

OnReceive是回调函数，在接收一次信息或者缓冲区满后会执行此函数。

运行测试程序，如图2，可以抓取到指定端口的数据。

##0231ST=32;CN=2011;PW=123456;MN=52808009210026;Flag=0;CP=&&DataTime=20190220151400;B01-Rtd=10.0000,B01-Flag=N;011-Rtd=17.140,011-Flag=N;060-Rtd=1.024,060-Flag=N;101-Rtd=0.211,101-Flag=N;065-Rtd=9.96,065-Flag=N1;001-Rtd=6.95,001-Flag=N&&3480

这条数据是由MN号是52808009210026的数采仪发送而来的。我们在通讯平台的日志中去查看(见图3)，也可以查到这条数据，说明我们抓取到的数据和系统接收到的数据是一致的，证明了数据有被窃取的可能。

图2 实验程序运行结果图Fig.2 Experimental program running results

图3 通讯平台日志截图Fig.3 Communication platform log screenshot

结论：通过实验，重现了数据被窃取的场景，所以监控数据在传输中存在被监听的隐患。

3.2 数据来源真实性无法确定

“212协议”上位机(数据接收方)的机制是一直监听通讯服务器的5003端口，收到数据以后进行CRC校验，校验无误就按照“212协议”规则将数据存入数据库。对数据是以MN号来区分的，并未验证数据是从哪个设备发送出来的，现场机(数据发送方)有可能按照“212协议”的规则编写虚拟的污染源监测数据，并用程序向上位机发送数据，上位机无法判断数据来源。换句话说，不法分子可以在任何能通过网络连通上位机的地方，用虚假的现场机向上位机发送数据，这些数据是可以人为控制的[3]。

下面，通过一个实验来验证这种隐患存在的真实性，我编写一个网络信息发送程序，以下是核心代码(见图4)。

图4 信息发送程序部分代码截图Fig.4 Screenshot of the code of the information sending program

这段代码的功能是将文本框tbMsg的内容发送到指定的IP端口下。

按照“212协议”规则编写一段信息，然后将此信息发送到通讯服务器，信息如下：

##0147ST=32;CN=2011;PW=123456;MN=92118209310014;CP=&&DataTime=20190225111730;B01-Rtd=0.000,B01-Flag=D;001-Rtd=7.678,001-Flag=N;011-Rtd=8.689,011-Flag=N&&6600

001-Rtd是ph值的实时数据编码，设定数据为7.678, 011-Rtd是化学需氧量的的数据编码，设定数据为8.689，设定数据发送时间是20190225111730，然后计算出CRC校验码，加上数据头。

程序运行如图5。

图5 数据发送程序界面Fig.5 Data transmission program screenshot

运行程序后，在数据展示页面查看到，我们发送的数据显示出来了(高亮显示部分)，数据和我设置的数据一样(见图6)。

结论一：本实验中，重现了人为定制的虚假数据发送到上位机的过程。换句话说，不法分子可以利用此程序漏洞伪造虚假的在线监控数据。

结论二：有一种更严重情况，A企业可以模拟B企业的数据发送到上位机，来“陷害”B企业，以此给B企业带来损失，达到恶性竞争的目的。

图6 在线监控页面截图Fig.6 Monitoring software page screenshot

3.3 数据的法律效率会引起异议。

目前的污染源在线自动监控数据已经逐步用于排污费征收的计算，数据越来越重要。但是由于以上两个问题的存在，如果要从行政职能上以污染源在线监控数据对企业进行处罚、征缴排污费，被处罚对象可能会对数据的真实性提出异议。比如否认超标或者异常的数据不是从自己的现场机发送出来的，再比如数据在传输途中有可能被修改过。作为监管部门，也无法排除这种可能性。

4 污染源数据安全解决方案

根据上文对污染源自动监控工作中存在问题的描述，为了保障污染源自动监控数据的安全，我认为要解决以下几个问题。

问题一：数据传输过程中存在被窃听的隐患。

针对此问题，要对发送的的数据进行加密后在传输，舍弃明文传输，即使数据在传输过程中被窃听，窃听者也无法识别数据内容。网络传输数据加密可以分为对称加密算法(加密效率高，加密时间短)和非对称加密算法(在公开的网络环境中可安全的传递密钥)。由于数据信息较长，为了节省数据传输处理时间，可以对数据信息采用加密效率高的对称加密算法，以提高加密速度。对称加密算法所使用的加密密钥采用非对称加密算法加密后传输，非对称加密算法的特点是能保障传输的信息(加密密钥)的传输安全，而不担心被窃取。如此可以保证数据的机密性。

问题二：数据来源真实性无法确定。

确认数据来源的真实性，要求上位机能确认数据来源，现场机不能抵赖数据的发送。

采用数字签名可解决这个问题，数字签名(digital signature)使用公钥密码技术，其特点是：只有拥有私钥的用户可以生成签名，用公钥解密签名称为验证签名。根据数学原理，私钥是唯一的，产生的签名也是唯一的，因此数字签名可以保证现场机不能抵赖对数据报文的签名，上位机可通过验证数字签名，确信现场机的身份及发出消息的事实。

通常情况下，由于要发送的数据原文比较长，直接对原文进行数字签名会耗费更多的时间。为了解决这个问题，可采用数据摘要算法(如SHA)计算出数据原文的摘要，数据摘要和数据原文具有唯一对应性，对数据摘要签名和对数据原文签名有相同的效果。且数据摘要长度短，对数据摘要签名能节省数据传输时间。同时，上位机在接收到数据后用同样的算法再次计算数据摘要，并进行比对，可验证数据的完整性。

问题三：数据的法律效率问题。

2005年颁布的《中华人民共和国电子签名法》，是电子签名具备法律效率的基本依据，其第十四条规定，可靠的电子签名与手写签名或者盖章具有同等的法律效力。第十三条规定了可靠的电子签名的定义，同时符合下列条件即视为可靠的电子签名：电子签名制作数据用于电子签名时，属于电子签名人专有；签署电子签名制作数据仅有电子签名人控制；签署后对电子签名的任何改动能够被发现；签署后对数据电文的内容和形式的任何改动能够被发现[4]。

数字签名是一种最常用的电子签名，其采用的公钥加密算法可以保障签名的专有性，且私钥只掌握在签名人手中可以保障签名制作的唯一性，通过比对数据摘要可以验证签名和数据电文内容和形式是否发生改动。由此可见，数字签名是可靠的电子签名，其合法性和有效性已经通过了法律的确认。

下面模拟采用数字签名的现场机(A)与上位机(B)通讯过程(图7)。

注：图中序号对应以上通讯过程中的步骤。图7 现场机与上位机通讯流程图：Fig.7 Flow chart of communication between field computer and host computer

(1)现场机按照“212协议”生成好要传送的信息(明文);

(2)现场机对信息进行哈希运算，得到一个信息摘要;

(3)现场机用自己的私钥对信息摘要进行加密得到现场机的数字签名，并将其附在数字信息后；

(4)现场机 随机产生一个加密密钥，并用此密码对要发送的信息进行加密，形成密文;

(5)现场机用上位机的公钥对刚才随机产生的加密密钥进行加密，将加密后的对称密钥连同密文一起传送给上位机;

(6)上位机收到现场机传送来的密文和加密过的对称密钥，先用自己的私钥对加密的对称密钥进行解密，得到现场机随机产生的加密密钥;

(7)上位机然后用随机密钥对收到的密文进行解密，得到明文的信息，然后将随机密钥抛弃;

(8)上位机用现场机的公钥对现场机的数字签名进行解密，得到信息摘要;

(9)上位机用相同的哈希算法对收到的明文再进行一次哈希运算，得到一个新的信息摘要;

(10)上位机将收到的信息摘要和新产生的信息摘要进行比较，如果一致，说明收到的信息没有被修改过，通讯结束。

5 结 论

通过本文的论述，我们可以得出结论，“212协议”的修订，是根据新的环境保护工作要求和形势做出的修订，更加切合工作实际，但通过几个实验，发现2017版“212协议”未对保障数据传输安全提出要求，存在安全隐患，建议在下次修订时能将数据传输安全要求纳入考虑。