污染物在線監(jiān)控系統(tǒng)數(shù)據(jù)傳輸標(biāo)準(zhǔn)與數(shù)據(jù)傳輸安全研究

2019-10-25 02:08:52胡海濤

四川環(huán)境 2019年5期

胡海濤

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

1 前言

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

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

本文通過對比兩個版本的“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)測儀器儀表與數(shù)采儀的通訊方式3個大項(xiàng)，通訊協(xié)議修訂內(nèi)容最多，包括通訊協(xié)議結(jié)構(gòu)、數(shù)據(jù)段結(jié)構(gòu)、數(shù)據(jù)字段(新增10個、修改1個、去除15個)、系統(tǒng)編碼(新增7個)、執(zhí)行結(jié)果(新增4個)、請求命令(7個)、命令編碼(新增17個、減少11個)9個小項(xiàng)[1-2]。

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

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

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

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

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

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

2.4 修改部分?jǐn)?shù)據(jù)段長度錯誤

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

圖1 新版協(xié)議對數(shù)據(jù)段結(jié)構(gòu)長度值修正示意圖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

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

2.5.2 修改1個字段

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

2.5.3 去除15個字段

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

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

2.6 系統(tǒng)編碼表

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

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

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

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

2.6.3 新增7個請求返回編碼

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

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

2.7 命令列表

2.7.1 新增命令

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

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

2.7.2 減少命令

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

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

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

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

3 污染源自動監(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ù)。如此會造成數(shù)據(jù)的泄露，影響數(shù)據(jù)安全。

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

為了能直觀的看到竊聽效果，簡化實(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ù)奈廴驹醋詣颖O(jiān)控數(shù)據(jù)。

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

新建一個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的時候，系統(tǒng)會開啟一個獨(dú)立的線程，用以執(zhí)行回調(diào)函數(shù)及，直到EndReceive從socket的緩沖區(qū)中讀到數(shù)據(jù)。

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

運(yùn)行測試程序，如圖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號是52808009210026的數(shù)采儀發(fā)送而來的。我們在通訊平臺的日志中去查看(見圖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 通訊平臺日志截圖Fig.3 Communication platform log screenshot

結(jié)論：通過實(shí)驗(yàn)，重現(xiàn)了數(shù)據(jù)被竊取的場景，所以監(jiān)控數(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ù)庫。對數(shù)據(jù)是以MN號來區(qū)分的，并未驗(yàn)證數(shù)據(jù)是從哪個設(shè)備發(fā)送出來的，現(xiàn)場機(jī)(數(shù)據(jù)發(fā)送方)有可能按照“212協(xié)議”的規(guī)則編寫虛擬的污染源監(jiān)測數(shù)據(jù)，并用程序向上位機(jī)發(fā)送數(shù)據(jù)，上位機(jī)無法判斷數(shù)據(jù)來源。換句話說，不法分子可以在任何能通過網(wǎng)絡(luò)連通上位機(jī)的地方，用虛假的現(xiàn)場機(jī)向上位機(jī)發(fā)送數(shù)據(jù)，這些數(shù)據(jù)是可以人為控制的[3]。

下面，通過一個實(shí)驗(yàn)來驗(yàn)證這種隱患存在的真實(shí)性，我編寫一個網(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ù)據(jù)編碼，設(shè)定數(shù)據(jù)為7.678, 011-Rtd是化學(xué)需氧量的的數(shù)據(jù)編碼，設(shè)定數(shù)據(jù)為8.689，設(shè)定數(shù)據(jù)發(fā)送時間是20190225111730，然后計算出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)控數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 結(jié) 論