胡海濤

(攀枝花市環(huán)境信息中心，四川 攀枝花 617000)

1 前 言

為貫徹《中華人民共和國環(huán)境保護(hù)法》，指導(dǎo)污染源在線自動(dòng)監(jiān)控(監(jiān)測(cè))系統(tǒng)的建設(shè)，規(guī)范數(shù)據(jù)傳輸，保證各種環(huán)境監(jiān)控監(jiān)測(cè)儀器、傳輸網(wǎng)絡(luò)和環(huán)保部門應(yīng)用軟件系統(tǒng)之間的連通，原國家環(huán)境保護(hù)總局于2005年12月30日發(fā)布了《污染源在線自動(dòng)監(jiān)控(監(jiān)測(cè))系統(tǒng)數(shù)據(jù)傳輸標(biāo)準(zhǔn)》(HJ/T212-2005)。

2017年5月1日，原環(huán)境保護(hù)部發(fā)布了《污染物在線監(jiān)控(監(jiān)測(cè))系統(tǒng)數(shù)據(jù)傳輸標(biāo)準(zhǔn)》(HJ212-2017)，代替HJ/T212-2005。以下簡(jiǎn)稱“212協(xié)議”。

本文通過對(duì)比兩個(gè)版本的“212協(xié)議”，分析協(xié)議的區(qū)別和變化，并通過分析總結(jié)，結(jié)合污染源在線監(jiān)控工作的經(jīng)驗(yàn)，提出我所發(fā)現(xiàn)的數(shù)據(jù)傳輸安全問題，并提出可能的解決方法。

2 “212協(xié)議”新版協(xié)議帶來的變化

“212協(xié)議”2017版和2005版相比較，頁碼從31頁增加到61頁，涉及到修訂的內(nèi)容包括協(xié)議層次、通訊協(xié)議、在線監(jiān)控監(jiān)測(cè)儀器儀表與數(shù)采儀的通訊方式3個(gè)大項(xiàng)，通訊協(xié)議修訂內(nèi)容最多，包括通訊協(xié)議結(jié)構(gòu)、數(shù)據(jù)段結(jié)構(gòu)、數(shù)據(jù)字段(新增10個(gè)、修改1個(gè)、去除15個(gè))、系統(tǒng)編碼(新增7個(gè))、執(zhí)行結(jié)果(新增4個(gè))、請(qǐng)求命令(7個(gè))、命令編碼(新增17個(gè)、減少11個(gè))9個(gè)小項(xiàng)[1-2]。

2.1 刪除自動(dòng)監(jiān)控設(shè)備模擬輸出接口

刪除了自動(dòng)監(jiān)控設(shè)備與數(shù)據(jù)采集傳輸儀之間的模擬接口。在實(shí)際工作中，自動(dòng)監(jiān)控設(shè)備監(jiān)測(cè)出的數(shù)據(jù)通過模擬接口傳輸?shù)綌?shù)據(jù)采集儀器上會(huì)產(chǎn)生誤差，目前我市的在線傳輸設(shè)備與數(shù)據(jù)采集傳輸儀器的通訊基本使用了數(shù)字接口。

2.2 刪除了非TCP/IP協(xié)議傳輸方式

在2017版本協(xié)議中取消了基于非TCP/IP協(xié)議的傳輸方式，如公共電話交換網(wǎng)和短消息通信，由于傳輸速率和實(shí)時(shí)性差等缺點(diǎn)的存在，在網(wǎng)絡(luò)通訊技術(shù)高速發(fā)展的今天，已經(jīng)很少有采用此種通訊方式進(jìn)行通訊的。

2.3 增加了7個(gè)通信介質(zhì)

“212協(xié)議”是構(gòu)建在TCP/IP協(xié)議上，從2005年第一版發(fā)布，到2017年修訂的第二版，期間多種通信介質(zhì)應(yīng)用于日常工作、生活中，此次修訂也將這些通信介質(zhì)納入到標(biāo)準(zhǔn)中。包括：寬頻分碼多重存取(WCDMA)、時(shí)分同步CDMA、寬帶CDMA(CDMA2000)、電力線通訊(PLC)、分時(shí)長(zhǎng)期演進(jìn)(TD-LTE)、微波存取全球互通(WiMAX)。

2.4 修改部分?jǐn)?shù)據(jù)段長(zhǎng)度錯(cuò)誤

2017版的協(xié)議中，修正了部分?jǐn)?shù)據(jù)段的長(zhǎng)度數(shù)值計(jì)算規(guī)則，使全部數(shù)據(jù)段的長(zhǎng)度值計(jì)算規(guī)則統(tǒng)一了。即數(shù)據(jù)段的長(zhǎng)度應(yīng)包含名稱以及“=”符號(hào)。在2005版協(xié)議中總包數(shù)PNUM、包號(hào)PNO、訪問密碼、設(shè)備唯一標(biāo)識(shí)、拆分包及應(yīng)答標(biāo)志5個(gè)數(shù)據(jù)段的長(zhǎng)度不包含名稱以及“=”符號(hào)。比如，請(qǐng)求編號(hào)PNUM定義長(zhǎng)度是4位，這4位是不包含“PNUM=”字符的，在2017版中予以了修正。如圖1。

圖1 新版協(xié)議對(duì)數(shù)據(jù)段結(jié)構(gòu)長(zhǎng)度值修正示意圖Fig.1 Schematic diagram of data segment structure length correction in the new version of protocol

2.5 字段變化

2.5.1 新增10個(gè)字段(表1)

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

新增加的字段補(bǔ)充了污染治理設(shè)施的參數(shù)(RestartTime、NewPW)，增加了現(xiàn)場(chǎng)端采樣的相關(guān)參數(shù)(MinIterval、xxxxxx-SampleTime、VaseNO、CstartTIme、Stime)，為實(shí)際工作中現(xiàn)場(chǎng)端取樣提供了標(biāo)準(zhǔn)。

2.5.2 修改1個(gè)字段

修改了SBxxx-RS字段。SBxxx-RS是污染治理設(shè)施運(yùn)行狀態(tài)的實(shí)時(shí)采樣值，增加了校準(zhǔn)、維護(hù)、報(bào)警、反吹狀態(tài)值。

2.5.3 去除15個(gè)字段

去除了QN請(qǐng)求編號(hào)，xxx-Ala污染物報(bào)警期間內(nèi)采樣值、xxx-UpValue污染物報(bào)警上限值、xxx-Lowvalue污染物報(bào)警下限值、AlarmTime超標(biāo)開始時(shí)間、AlarmType報(bào)警時(shí)間類型、ReportTarget上位機(jī)地址標(biāo)識(shí)、ReportTime數(shù)據(jù)上報(bào)時(shí)間信息、DayStdValue噪聲白天報(bào)警上限值、NightStdValue噪聲夜晚報(bào)警上限值、Flag通訊標(biāo)志、PNO包序號(hào)、PNUM總包號(hào)、PW訪問密碼、WarnTime超限報(bào)警時(shí)間。

去除的字段大多和報(bào)警參數(shù)有關(guān)，數(shù)據(jù)傳輸?shù)缴衔粰C(jī)以后，上位機(jī)可自行根據(jù)報(bào)警值進(jìn)行分析，無需從現(xiàn)場(chǎng)機(jī)傳輸此狀態(tài)。另外PNO、PNUM、PW 3個(gè)字段在通訊包的數(shù)據(jù)段中已有定義，無需在數(shù)據(jù)區(qū)中再次定義。

2.6 系統(tǒng)編碼表

2.6.1 新增7個(gè)監(jiān)測(cè)類別編碼

新增7個(gè)監(jiān)測(cè)類別，如下：地下水質(zhì)量監(jiān)測(cè)，編碼24;土壤質(zhì)量監(jiān)測(cè)，編碼25;海水質(zhì)量監(jiān)測(cè)，編號(hào)26;揮發(fā)性有機(jī)物監(jiān)測(cè)，編號(hào)27；工地?fù)P塵污染源，編號(hào)39；煙氣排放過程監(jiān)控，編號(hào)51；污水排放過程監(jiān)控，編號(hào)52。

2.6.2 新增4個(gè)執(zhí)行結(jié)果編碼

豐富了執(zhí)行結(jié)果，2005版協(xié)議中，只有執(zhí)行成功和執(zhí)行失敗，本次修訂新增了命令請(qǐng)求條件錯(cuò)誤，編號(hào)3；通訊超時(shí)，編號(hào)4；系統(tǒng)繁忙不能執(zhí)行，編號(hào)5；系統(tǒng)故障，編號(hào)6。

2.6.3 新增7個(gè)請(qǐng)求返回編碼

新增7個(gè)請(qǐng)求返回編碼，告知6種錯(cuò)誤狀態(tài)，和一個(gè)未知的錯(cuò)誤狀態(tài)(表2)。

表2 新增請(qǐng)求命令返回表Tab.2 New request command return table

2.7 命令列表

2.7.1 新增命令

新增了現(xiàn)場(chǎng)機(jī)狀態(tài)、采樣、標(biāo)識(shí)等命令(表3)。

表3 新增命令編碼表Tab.3 New command code table

2.7.2 減少命令

減少了報(bào)警、上位機(jī)地址相關(guān)的命令(表4)。

表4 減少命令編碼表Tab.4 Reduce command code table

2.8 增加在線監(jiān)控(監(jiān)測(cè))儀器儀表與數(shù)采儀的通訊方式

2017版本加強(qiáng)對(duì)在線監(jiān)控(監(jiān)測(cè))儀器的管理，明確接口采用RS-485接口，協(xié)議采用Modbus RTU協(xié)議。

3 污染源自動(dòng)監(jiān)控工作中存在的問題

通過研究，我發(fā)現(xiàn)了“212協(xié)議”存在的如下隱患。

3.1 數(shù)據(jù)傳輸過程中存在被竊聽的隱患

“212協(xié)議”工作在TCP/IP的應(yīng)用層，是明文傳輸?shù)模嬖诒桓`聽的在可能，可以在網(wǎng)絡(luò)數(shù)據(jù)傳輸、交換的過程中偵聽竊取數(shù)據(jù)。如此會(huì)造成數(shù)據(jù)的泄露，影響數(shù)據(jù)安全。

下面通過一個(gè)實(shí)驗(yàn)來驗(yàn)證偵聽數(shù)據(jù)的可能性。

為了能直觀的看到竊聽效果，簡(jiǎn)化實(shí)驗(yàn)，直接在通訊服務(wù)器上監(jiān)聽用于接收數(shù)據(jù)的端口。

實(shí)驗(yàn)環(huán)境：windows server 2012

實(shí)驗(yàn)工具：Visual studio 2017

實(shí)驗(yàn)方法：編寫C# Winform程序，監(jiān)聽服務(wù)器本地連接的5003端口，看是否可能獲取到傳輸?shù)奈廴驹醋詣?dòng)監(jiān)控?cái)?shù)據(jù)。

實(shí)驗(yàn)介紹：使用Socket套件字異步通訊，獲取所有通過的數(shù)據(jù)包。以下是主要實(shí)現(xiàn)代碼片段：

新建一個(gè)Socket，使用SocketType.Raw，raw socket是原始套接字，工作在網(wǎng)絡(luò)層或數(shù)據(jù)鏈路層。使用raw socket進(jìn)行數(shù)據(jù)監(jiān)聽，在交換式網(wǎng)絡(luò)中能接收到發(fā)向自己的包和以廣播方式發(fā)的包。

Socket.BeginReceive是用于客戶端和服務(wù)器端異步通訊，byteData數(shù)組用于接受數(shù)據(jù)的。AsyncCallBack委托是為接受數(shù)據(jù)后的回調(diào)函數(shù)。調(diào)用BeginReceive的時(shí)候，系統(tǒng)會(huì)開啟一個(gè)獨(dú)立的線程，用以執(zhí)行回調(diào)函數(shù)及，直到EndReceive從socket的緩沖區(qū)中讀到數(shù)據(jù)。

OnReceive是回調(diào)函數(shù)，在接收一次信息或者緩沖區(qū)滿后會(huì)執(zhí)行此函數(shù)。

運(yùn)行測(cè)試程序，如圖2，可以抓取到指定端口的數(shù)據(jù)。

##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

這條數(shù)據(jù)是由MN號(hào)是52808009210026的數(shù)采儀發(fā)送而來的。我們?cè)谕ㄓ嵠脚_(tái)的日志中去查看(見圖3)，也可以查到這條數(shù)據(jù)，說明我們抓取到的數(shù)據(jù)和系統(tǒng)接收到的數(shù)據(jù)是一致的，證明了數(shù)據(jù)有被竊取的可能。

圖2 實(shí)驗(yàn)程序運(yùn)行結(jié)果圖Fig.2 Experimental program running results

圖3 通訊平臺(tái)日志截圖Fig.3 Communication platform log screenshot

結(jié)論：通過實(shí)驗(yàn)，重現(xiàn)了數(shù)據(jù)被竊取的場(chǎng)景，所以監(jiān)控?cái)?shù)據(jù)在傳輸中存在被監(jiān)聽的隱患。

3.2 數(shù)據(jù)來源真實(shí)性無法確定

“212協(xié)議”上位機(jī)(數(shù)據(jù)接收方)的機(jī)制是一直監(jiān)聽通訊服務(wù)器的5003端口，收到數(shù)據(jù)以后進(jìn)行CRC校驗(yàn)，校驗(yàn)無誤就按照“212協(xié)議”規(guī)則將數(shù)據(jù)存入數(shù)據(jù)庫。對(duì)數(shù)據(jù)是以MN號(hào)來區(qū)分的，并未驗(yàn)證數(shù)據(jù)是從哪個(gè)設(shè)備發(fā)送出來的，現(xiàn)場(chǎng)機(jī)(數(shù)據(jù)發(fā)送方)有可能按照“212協(xié)議”的規(guī)則編寫虛擬的污染源監(jiān)測(cè)數(shù)據(jù)，并用程序向上位機(jī)發(fā)送數(shù)據(jù)，上位機(jī)無法判斷數(shù)據(jù)來源。換句話說，不法分子可以在任何能通過網(wǎng)絡(luò)連通上位機(jī)的地方，用虛假的現(xiàn)場(chǎng)機(jī)向上位機(jī)發(fā)送數(shù)據(jù)，這些數(shù)據(jù)是可以人為控制的[3]。

下面，通過一個(gè)實(shí)驗(yàn)來驗(yàn)證這種隱患存在的真實(shí)性，我編寫一個(gè)網(wǎng)絡(luò)信息發(fā)送程序，以下是核心代碼(見圖4)。

圖4 信息發(fā)送程序部分代碼截圖Fig.4 Screenshot of the code of the information sending program

這段代碼的功能是將文本框tbMsg的內(nèi)容發(fā)送到指定的IP端口下。

按照“212協(xié)議”規(guī)則編寫一段信息，然后將此信息發(fā)送到通訊服務(wù)器，信息如下：

##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值的實(shí)時(shí)數(shù)據(jù)編碼，設(shè)定數(shù)據(jù)為7.678, 011-Rtd是化學(xué)需氧量的的數(shù)據(jù)編碼，設(shè)定數(shù)據(jù)為8.689，設(shè)定數(shù)據(jù)發(fā)送時(shí)間是20190225111730，然后計(jì)算出CRC校驗(yàn)碼，加上數(shù)據(jù)頭。

程序運(yùn)行如圖5。

圖5 數(shù)據(jù)發(fā)送程序界面Fig.5 Data transmission program screenshot

運(yùn)行程序后，在數(shù)據(jù)展示頁面查看到，我們發(fā)送的數(shù)據(jù)顯示出來了(高亮顯示部分)，數(shù)據(jù)和我設(shè)置的數(shù)據(jù)一樣(見圖6)。

結(jié)論一：本實(shí)驗(yàn)中，重現(xiàn)了人為定制的虛假數(shù)據(jù)發(fā)送到上位機(jī)的過程。換句話說，不法分子可以利用此程序漏洞偽造虛假的在線監(jiān)控?cái)?shù)據(jù)。

結(jié)論二：有一種更嚴(yán)重情況，A企業(yè)可以模擬B企業(yè)的數(shù)據(jù)發(fā)送到上位機(jī)，來“陷害”B企業(yè)，以此給B企業(yè)帶來損失，達(dá)到惡性競(jìng)爭(zhēng)的目的。

圖6 在線監(jiān)控頁面截圖Fig.6 Monitoring software page screenshot

3.3 數(shù)據(jù)的法律效率會(huì)引起異議。

目前的污染源在線自動(dòng)監(jiān)控?cái)?shù)據(jù)已經(jīng)逐步用于排污費(fèi)征收的計(jì)算，數(shù)據(jù)越來越重要。但是由于以上兩個(gè)問題的存在，如果要從行政職能上以污染源在線監(jiān)控?cái)?shù)據(jù)對(duì)企業(yè)進(jìn)行處罰、征繳排污費(fèi)，被處罰對(duì)象可能會(huì)對(duì)數(shù)據(jù)的真實(shí)性提出異議。比如否認(rèn)超標(biāo)或者異常的數(shù)據(jù)不是從自己的現(xiàn)場(chǎng)機(jī)發(fā)送出來的，再比如數(shù)據(jù)在傳輸途中有可能被修改過。作為監(jiān)管部門，也無法排除這種可能性。

4 污染源數(shù)據(jù)安全解決方案

根據(jù)上文對(duì)污染源自動(dòng)監(jiān)控工作中存在問題的描述，為了保障污染源自動(dòng)監(jiān)控?cái)?shù)據(jù)的安全，我認(rèn)為要解決以下幾個(gè)問題。

問題一：數(shù)據(jù)傳輸過程中存在被竊聽的隱患。

針對(duì)此問題，要對(duì)發(fā)送的的數(shù)據(jù)進(jìn)行加密后在傳輸，舍棄明文傳輸，即使數(shù)據(jù)在傳輸過程中被竊聽，竊聽者也無法識(shí)別數(shù)據(jù)內(nèi)容。網(wǎng)絡(luò)傳輸數(shù)據(jù)加密可以分為對(duì)稱加密算法(加密效率高，加密時(shí)間短)和非對(duì)稱加密算法(在公開的網(wǎng)絡(luò)環(huán)境中可安全的傳遞密鑰)。由于數(shù)據(jù)信息較長(zhǎng)，為了節(jié)省數(shù)據(jù)傳輸處理時(shí)間，可以對(duì)數(shù)據(jù)信息采用加密效率高的對(duì)稱加密算法，以提高加密速度。對(duì)稱加密算法所使用的加密密鑰采用非對(duì)稱加密算法加密后傳輸，非對(duì)稱加密算法的特點(diǎn)是能保障傳輸?shù)男畔?加密密鑰)的傳輸安全，而不擔(dān)心被竊取。如此可以保證數(shù)據(jù)的機(jī)密性。

問題二：數(shù)據(jù)來源真實(shí)性無法確定。

確認(rèn)數(shù)據(jù)來源的真實(shí)性，要求上位機(jī)能確認(rèn)數(shù)據(jù)來源，現(xiàn)場(chǎng)機(jī)不能抵賴數(shù)據(jù)的發(fā)送。

采用數(shù)字簽名可解決這個(gè)問題，數(shù)字簽名(digital signature)使用公鑰密碼技術(shù)，其特點(diǎn)是：只有擁有私鑰的用戶可以生成簽名，用公鑰解密簽名稱為驗(yàn)證簽名。根據(jù)數(shù)學(xué)原理，私鑰是唯一的，產(chǎn)生的簽名也是唯一的，因此數(shù)字簽名可以保證現(xiàn)場(chǎng)機(jī)不能抵賴對(duì)數(shù)據(jù)報(bào)文的簽名，上位機(jī)可通過驗(yàn)證數(shù)字簽名，確信現(xiàn)場(chǎng)機(jī)的身份及發(fā)出消息的事實(shí)。

通常情況下，由于要發(fā)送的數(shù)據(jù)原文比較長(zhǎng)，直接對(duì)原文進(jìn)行數(shù)字簽名會(huì)耗費(fèi)更多的時(shí)間。為了解決這個(gè)問題，可采用數(shù)據(jù)摘要算法(如SHA)計(jì)算出數(shù)據(jù)原文的摘要，數(shù)據(jù)摘要和數(shù)據(jù)原文具有唯一對(duì)應(yīng)性，對(duì)數(shù)據(jù)摘要簽名和對(duì)數(shù)據(jù)原文簽名有相同的效果。且數(shù)據(jù)摘要長(zhǎng)度短，對(duì)數(shù)據(jù)摘要簽名能節(jié)省數(shù)據(jù)傳輸時(shí)間。同時(shí)，上位機(jī)在接收到數(shù)據(jù)后用同樣的算法再次計(jì)算數(shù)據(jù)摘要，并進(jìn)行比對(duì)，可驗(yàn)證數(shù)據(jù)的完整性。

問題三：數(shù)據(jù)的法律效率問題。

2005年頒布的《中華人民共和國電子簽名法》，是電子簽名具備法律效率的基本依據(jù)，其第十四條規(guī)定，可靠的電子簽名與手寫簽名或者蓋章具有同等的法律效力。第十三條規(guī)定了可靠的電子簽名的定義，同時(shí)符合下列條件即視為可靠的電子簽名：電子簽名制作數(shù)據(jù)用于電子簽名時(shí)，屬于電子簽名人專有；簽署電子簽名制作數(shù)據(jù)僅有電子簽名人控制；簽署后對(duì)電子簽名的任何改動(dòng)能夠被發(fā)現(xiàn)；簽署后對(duì)數(shù)據(jù)電文的內(nèi)容和形式的任何改動(dòng)能夠被發(fā)現(xiàn)[4]。

數(shù)字簽名是一種最常用的電子簽名，其采用的公鑰加密算法可以保障簽名的專有性，且私鑰只掌握在簽名人手中可以保障簽名制作的唯一性，通過比對(duì)數(shù)據(jù)摘要可以驗(yàn)證簽名和數(shù)據(jù)電文內(nèi)容和形式是否發(fā)生改動(dòng)。由此可見，數(shù)字簽名是可靠的電子簽名，其合法性和有效性已經(jīng)通過了法律的確認(rèn)。

下面模擬采用數(shù)字簽名的現(xiàn)場(chǎng)機(jī)(A)與上位機(jī)(B)通訊過程(圖7)。

注：圖中序號(hào)對(duì)應(yīng)以上通訊過程中的步驟。圖7 現(xiàn)場(chǎng)機(jī)與上位機(jī)通訊流程圖：Fig.7 Flow chart of communication between field computer and host computer

(1)現(xiàn)場(chǎng)機(jī)按照“212協(xié)議”生成好要傳送的信息(明文);

(2)現(xiàn)場(chǎng)機(jī)對(duì)信息進(jìn)行哈希運(yùn)算，得到一個(gè)信息摘要;

(3)現(xiàn)場(chǎng)機(jī)用自己的私鑰對(duì)信息摘要進(jìn)行加密得到現(xiàn)場(chǎng)機(jī)的數(shù)字簽名，并將其附在數(shù)字信息后；

(4)現(xiàn)場(chǎng)機(jī) 隨機(jī)產(chǎn)生一個(gè)加密密鑰，并用此密碼對(duì)要發(fā)送的信息進(jìn)行加密，形成密文;

(5)現(xiàn)場(chǎng)機(jī)用上位機(jī)的公鑰對(duì)剛才隨機(jī)產(chǎn)生的加密密鑰進(jìn)行加密，將加密后的對(duì)稱密鑰連同密文一起傳送給上位機(jī);

(6)上位機(jī)收到現(xiàn)場(chǎng)機(jī)傳送來的密文和加密過的對(duì)稱密鑰，先用自己的私鑰對(duì)加密的對(duì)稱密鑰進(jìn)行解密，得到現(xiàn)場(chǎng)機(jī)隨機(jī)產(chǎn)生的加密密鑰;

(7)上位機(jī)然后用隨機(jī)密鑰對(duì)收到的密文進(jìn)行解密，得到明文的信息，然后將隨機(jī)密鑰拋棄;

(8)上位機(jī)用現(xiàn)場(chǎng)機(jī)的公鑰對(duì)現(xiàn)場(chǎng)機(jī)的數(shù)字簽名進(jìn)行解密，得到信息摘要;

(9)上位機(jī)用相同的哈希算法對(duì)收到的明文再進(jìn)行一次哈希運(yùn)算，得到一個(gè)新的信息摘要;

(10)上位機(jī)將收到的信息摘要和新產(chǎn)生的信息摘要進(jìn)行比較，如果一致，說明收到的信息沒有被修改過，通訊結(jié)束。

5 結(jié) 論

通過本文的論述，我們可以得出結(jié)論，“212協(xié)議”的修訂，是根據(jù)新的環(huán)境保護(hù)工作要求和形勢(shì)做出的修訂，更加切合工作實(shí)際，但通過幾個(gè)實(shí)驗(yàn)，發(fā)現(xiàn)2017版“212協(xié)議”未對(duì)保障數(shù)據(jù)傳輸安全提出要求，存在安全隱患，建議在下次修訂時(shí)能將數(shù)據(jù)傳輸安全要求納入考慮。