一種適用于園區微電網的安全控制協議

陳藝琳，羅嬌燕，胡逸芳，易傳佳，左黎明

(華東交通大學 理學院，江西 南昌 330013)

0 引 言

隨著風能、太陽能、天然氣等清潔能源開發技術的不斷突破，分布式電源[1]逐漸得到發展。分布式電源可以較好地避免集中供電技術存在的環境破壞和資源浪費問題。隨著分布式電源并入到配電網中，為了有效提高分布式電源的利用效率，微電網[2-5]的概念被提出。微電網系統可以促進可再生能源的開發與利用，為負荷提供穩定可靠的電能。在微電網技術快速發展的背景下，面向園區的微電網[6-8]建設也在快速發展。穩定可靠的電力供應是園區正常生產和運營的重要保障，園區微電網的安全控制是保障園區正常運轉的關鍵。微電網的控制成為近年來的研究熱點[9-12]，文獻[13]針對微電網控制器成本高、集成度低等問題提出一種基于嵌入式系統的園區微電網中央控制器，并驗證了中央控制器的功能和能量管理策略具有較好的實用性。微電網的控制系統依賴于大量的數據采集與交互，在網絡攻擊層出不窮的互聯網環境下，微電網的正常運營面臨著網絡攻擊的威脅。2015年和2016年末烏克蘭曾發生由黑客組織進攻導致的大面積停電事故，2019年3月委內瑞拉電網遭到網絡攻擊，導致全國18個州范圍電力中斷超過24小時。此類停電事故造成了巨大的經濟損失，為避免此類事故的發生，相關網絡安全研究者和電網機構開始對電網和微電網的安全性進行研究[14-16]。園區微電網的控制系統中，包含有園區大量電力設備的用電數據，攻擊者一旦通過網絡攻擊手段竊取或篡改微電網數據，很可能使園區微電網以及其他生產設備發生故障，從而導致園區產生重大安全事故和經濟損失。針對園區微電網控制系統中可能存在的信息安全問題，該文提出一種消息可恢復數字簽名方案，并基于該方案設計一種適用于園區微電網的安全控制協議，在保證通信效率的前提下，有效保障微電網控制系統數據交互的安全性，保障園區微電網穩定運行。

1 相關基礎

1.1 園區微電網控制系統

園區微電網是一個可以實現自我控制、保護和管理的自治系統，主要為商業園區或工業園區提供電能服務。

如圖1所示，園區微電網主要包括光伏電源、儲能裝置、電力負荷等設備。園區微電網通過公共連接點(point of common coupling，PCC)與配電網連接，PCC處的靜態開關可以實現微電網在孤網和并網兩種運行狀態間的平滑切換。在該文所描述的園區微電網中，分布式能源為太陽能，光伏電源和儲能裝置負責對多個負荷端提供電能和電壓支撐，這樣可以有效節約從大電網購買電力而產生的經濟成本，同時也有效降低了電力傳輸的負擔。在大電網發生突發故障或電能質量不達標時，PCC處的靜態開關斷開與配電網的連接，園區微電網從并網模式平滑切換至孤網模式獨立運行，這種方式有效降低了由于主網故障帶來的影響，提高了園區供電的可靠性與安全性，園區的正常運營也得到有效保障。

園區微電網的控制系統是整個園區微電網系統的核心部分，是維持園區微電網安全、穩定、高效運行的重要組成部分。目前主流的微電網控制系統為三層控制結構，分別為配電網調度層、集中控制層、本地控制層。控制系統由各部分控制裝置組成，可實現分布式電源控制、儲能裝置控制、孤網并網切換控制、微電網電能管理以及微電網實時監控等。

(1)配電網調度層。

配電網調度層是一個云服務端，可以實時采集各個控制裝置的數據，并將數據進行計算和分析。實時數據和計算分析結果可以在云服務端以圖表等形式實時顯示。云服務端根據計算分析結果給各個控制裝置下達控制指令，同時也能接受上級配電網的調節控制指令，從微電網安全、經濟運行的角度協調和調度微電網。

(2)集中控制層。

集中控制層是微電網的控制中心，也是整個微電網控制系統的核心部分，主要控制裝置為中央控制器。中央控制器對分布式電源、儲能裝置、各個負荷的運行數據進行實時采集，對它們的運行狀態進行實時監控，并對采集的數據進行計算與分析，得出微電網的實時運行狀態。中央控制器可以接受配電網調度層的控制指令給出相應的控制動作。中央控制器根據實時運行狀態，實時優化控制策略，控制分布式電源、儲能裝置、負荷的啟動和停止，實現微電網并網狀態、孤網狀態的平滑切換，保障微電網穩定運行。

(3)本地控制層。

本地控制層由分布式電源控制器、儲能控制器、負荷控制器等控制設備組成，接受集中控制層的控制指令，同時通過分布式電源控制器調節分布式電源，通過儲能控制器實現儲能裝置的充放電控制，通過負荷控制器實現對負荷的控制。

在園區微電網的運行過程中，配電網調度層、集中控制層和本地控制層自上而下通過通信向下發送控制指令。在這個過程中存在網絡攻擊威脅的根源主要在于數據來源缺乏安全認證，該文提出的適用于園區微電網的安全控制協議基于消息可恢復簽名方案，可以通過數字簽名對數據來源進行安全認證，保障數據傳輸的可靠性。

1.2 消息可恢復簽名方案

消息可恢復的簽名方案由系統初始化、密鑰生成、簽名和驗證簽名四個算法組成，具體描述如下：

(1)系統初始化：給定安全參數，輸出系統參數，公開系統參數。

(2)密鑰生成：根據公開的系統參數，生成用戶的私鑰，并計算系統公鑰。

(3)簽名：輸入系統參數和用戶私鑰，輸出簽名，并發給驗證者。

(4)驗證簽名：輸入系統參數、簽名，輸出驗證結果，“TRUE”或者“FALSE”，輸出恢復的完整消息。

在園區微電網控制系統中，云服務端為簽名驗證者，中央控制器可以生成私鑰并定期更新私鑰。中央控制器發送數據封包時，先對數據封包進行簽名，然后發送給云服務端，當云服務端對簽名信息進行驗證，驗證成功則輸出恢復的完整消息，驗證失敗則發出警告信息。

2 消息可恢復簽名方案構造

基于橢圓曲線上離散對數問題的難解性，提出一種消息可恢復簽名方案。為了方便方案描述，首先給出一些常用符號，符號對照如表1所示。

表1 符號說明

下面給出方案的詳細描述，方案主要由四個算法構成，具體描述如下：

(1)系統初始化。

(2)密鑰生成。

(3)簽名。

K=x1y2

(1)

R=rP

(2)

h1=H(m)||H(H(m))⊕m

(3)

h2=H(K,R)

(4)

s=h1⊕h2

(5)

e=sx1+rmodq

(6)

則(e,s)為消息m的簽名。

(4)簽名驗證。

對給定消息m的簽名(e,s)，驗證簽名的過程如下：

①依次計算：

R=eP-sy1

(7)

K=x2y1

(8)

(9)

整個簽名驗證和消息恢復過程正確性證明如下：

R=eP-sy1=sx1P+rP-sx1P=rP

(10)

K=x2y1=x2x1P=x1y2

(11)

(12)

(13)

(14)

(15)

H(H(m))⊕H(H(m))⊕m=m

(16)

3 安全控制協議設計

3.1 安全控制系統結構

在微電網系統中，中央控制器與云服務端的安全控制架構如圖2所示。在中央控制器中集成了數據采集模塊、數據處理模塊和簽名模塊，云服務端由身份認證模塊、信息處理模塊組成。

在中央控制器中，數據采集模塊負責微電網數據的采集，信息處理模塊負責數據格式的處理，將數據處理為規范的消息封包，簽名模塊負責對消息封包進行簽名。在云服務端，信息處理模塊負責對接受到的消息封包進行解析，簽名驗證模塊負責對中央控制器發送過來的簽名進行驗證及消息恢復。

3.2 安全協議設計

安全協議的交互過程如圖3所示。

步驟1：數據采集模塊采集實時數據，得到數據系列data1,data2,data3等。

步驟2：數據采集模塊將采集的數據系列data1,data2,data3發送到信息處理模塊。

步驟3：信息處理模塊接收到數據后，將數據處理成data1*data2*data3的封包格式，然后發送到簽名模塊。

步驟4：簽名模塊接收到消息封包后，調用簽名算法得到簽名Sig。

步驟5：簽名模塊將簽名結果Sig發送到云服務端。

步驟6：云服務端接收到消息封包后，簽名驗證模塊調用簽名驗證算法對消息封包進行簽名驗證，驗證通過則恢復消息，并把消息發送到信息處理模塊，驗證不通過則發出警告信息。

步驟7：信息處理模塊對消息封包進行解析，獲得原始數據。

4 安全性分析

4.1 數據機密性

當控制器與云服務端進行通信時，攻擊者可以對通信數據進行監聽。當通信數據以明文數據傳輸時，攻擊者可以竊取通信雙方的通信具體內容。在安全控制協議中，控制器會先將通信數據進行簽名處理再發送簽名，云服務端對簽名進行驗證，然后通過簽名進行消息恢復。通信的報文內容只含有簽名數據，不包括原始消息，原始消息不會暴露在通信過程中，從而保證了數據的機密性。

4.2 數據完整性

信息的完整性是指在存儲或傳輸信息的過程中，原始的信息不能允許被隨意更改。篡改攻擊是破壞數據完整性最常見的方法之一，篡改攻擊是指攻擊者對攔截到的報文進行篡改，將篡改后的報文進行發送達到攻擊目的。在安全控制協議中，當攻擊者對報文進行篡改并發送到服務端后，由于報文已經被篡改，服務端進行簽名驗證時會驗證失敗，無法對消息進行恢復。從而使得協議可以抵抗篡改攻擊，確保數據的完整性。

4.3 數據不可否認性保護

在網絡通信中，攻擊者常常利用冒充、偽造等方法向接收方發送報文，在安全控制協議中，采用了消息可恢復式簽名技術，服務端可以根據公開參數簽名者公開的公鑰對接收到的報文進行簽名驗證，可以有效地保障數據來源的可靠性。

5 實驗仿真

在Windows7 64位操作系統Microsoft Visual Studio 2012微軟平臺下，采用C#輕量級密碼術包(bouncy castle)實現了文中方案。實驗結果顯示該方案簽名所消耗時間為0.010秒，驗證所消耗時間為0.219秒。實現結果如圖4所示。

5.1 簽名生成過程

在中央控制器中，首先對采集的數據進行封包處理，然后通過該簽名方案對數據封包進行簽名處理，核心代碼如下：

ecc myecc=new ecc();

ECPoint y1=myecc.ecc_point_g.Multiply(x1);

ECPoint y2=myecc.ecc_point_g.Multiply(x2);

ECPoint K=y2.Multiply(x1);

ECPoint R=myecc.ecc_point_g.Multiply(r);

hash myhash=new hash();

byte[] hm=myhash.TanGetDigestByteArray(m);

//計算H(H(m))

byte[] hhm=myhash.TanGetDigestByteArray(hm);

//計算H(H(m))⊕m

byte[] hmxor=HexXorByte(hhm, m);

//計算h1

byte[] h1=new byte[64];

Array.Copy(hm, 0, h1, 0, 32);

Array.Copy(hmxor, 0, h1, 32, 32);

//計算h2

string KK=K.X.ToBigInteger().ToString() + K.Y.ToBigInteger().ToString();

string RR=R.X.ToBigInteger().ToString() + R.Y.ToBigInteger().ToString();

string KR=KK+RR;

byte[] h2=myhash.TanGetDigestByteArray512(KR);

//計算s=h1⊕h2

byte[] ss=HexXorByte(h1, h2);

//計算e

BigInteger s=new BigInteger(ss);

BigInteger sx1=s.Multiply(x1);

BigInteger e=sx1.Add(r.Mod(myecc.ecc_n));

5.2 簽名驗證過程

在云服務端，接收到中央控制器發送過來的數據封包后，根據該簽名方案的簽名驗證算法對簽名進行驗證，核心代碼如下：

ECPoint ep=myecc.ecc_point_g.Multiply(e);

ECPoint sy1=y1.Multiply(s);

ECPoint R1=ep.Subtract(sy1);

ECPoint K1=y1.Multiply(x2);

string KK1=K1.X.ToBigInteger().ToString()+K1.Y.ToBigInteger().ToString();

string RR1=R1.X.ToBigInteger().ToString()+R1.Y.ToBigInteger().ToString();

string KR1=KK1 + RR1;

byte[] H2=myhash.TanGetDigestByteArray512(KR1);

byte[] H1=HexXorByte(H2, ss);

byte[] H1L=new byte[32];

byte[] H1R=new byte[32];

Array.Copy(H1, 0, H1L, 0, 32);

Array.Copy(H1, 32, H1R, 0, 32);

byte[] HL=myhash.TanGetDigestByteArray(H1L);

//恢復消息m

byte[] m1=HexXorByte(HL, H1R);

byte[] left=H1L;

byte[] right=myhash.TanGetDigestByteArray(m1);

if (ByteEquals(left,right))

{

Console.WriteLine("驗證簽名通過！");

Console.WriteLine("消息恢復成功！");

Console.WriteLine("恢復的消息：{0}", Encoding.UTF8.GetString(m1));

}

else

{

Console.WriteLine("驗證簽名失敗！消息恢復失敗！");

}

5.3 協議性能分析

在Windows7 64位操作系統Microsoft Visual Studio 2012微軟平臺下，采用C#輕量級密碼術包(bouncy castle)運行文獻[16-20]中方案對應的協議,分別運行100次，計算簽名過程與驗證簽名的平均耗時并進行比較，各協議簽名過程與驗證簽名的平均耗時如圖5所示。

在簽名過程中，文獻[16]對應協議的簽名過程平均耗時0.022秒，文獻[17]平均耗時0.114秒，文獻[18]平均耗時0.038秒，文獻[19]平均耗時0.044秒，文獻[20]平均耗時0.032秒，文中方案簽名過程平均耗時為0.013秒。相比其他協議，文中方案的安全控制協議在簽名效率方面存在優勢。

在驗證簽名過程中，文中方案的驗證簽名過程平均耗時為0.22秒，相比文獻[16-20]的驗證簽名過程平均耗時都要高，這是由于驗證簽名的過程不僅需要簽名的驗證，而且需要消息的恢復，其計算復雜程度高于簽名過程。

綜合來看，文中方案協議的簽名過程運行效率較高，適合在計算能力差的設備上運行，驗證簽名過程運行效率一般，需要在計算能力高的設備上運行。在安全控制協議中主要針對的是中央控制器的性能，在中央控制器上進行的為簽名過程，驗證簽名在云服務端進行。在微電網控制系統的結構中，中央控制器受限于設備本身，在中央控制器運行的協議需要較高的運行效率，而云服務端采用的服務器集群，計算能力很高。因此，文中方案的簽名過程運行在中央控制器，驗證簽名過程運行在云服務端，可以保障協議的安全高效運行。

6 結束語

針對當前園區微電網控制系統在數據交互過程中存在安全性認證和數據完整性保護問題，提出了一種消息可恢復的數字簽名方案，并進一步設計了一種適用于園區微電網的安全控制協議。對安全控制協議進行了實驗與仿真，結果表明該方案在控制器端的效率較高。該方案應用到園區微電網的控制系統中，可以提高系統的安全性，保障園區微電網的安全穩定運行。