基于TLS1.3 協(xié)議的智能電表安全設(shè)計

季海濤，張芳敏，黃柳勝，孫孟玉，黃炳潔

（1.上海電力大學電子與信息工程學院，上海 200000；2.江蘇林洋能源股份有限公司，江蘇 啟東 226200）

智能電表作為電網(wǎng)中的終端設(shè)備，將信息流、業(yè)務(wù)流、電力流高度融合一體化，實現(xiàn)分布式計量、達到客戶與電表終端雙向互動服務(wù)。計量信息涉及用戶與供電部門的利益，數(shù)據(jù)安全防護至關(guān)重要。信息安全解決方案在AMI 聯(lián)網(wǎng)抄表系統(tǒng)及智能電網(wǎng)基礎(chǔ)設(shè)施中得以廣泛部署[1-2]，從各國的智能電網(wǎng)系統(tǒng)環(huán)境結(jié)合電表通信的規(guī)劃和應(yīng)用分析，各批次智能電表因存儲空間及CPU 等資源的局限性，更好地實現(xiàn)電表安全也因此受到限制。當下主流的安全方案也漸漸成為智能電表的需求。文獻[3]研究了一種新的基于分布式區(qū)塊鏈的保護方案，以增強電表抵御網(wǎng)絡(luò)攻擊的能力。IPsec 安全協(xié)議必須處理可靠性和分片的問題[4]。TLS 協(xié)議是應(yīng)用最為廣泛的安全通信協(xié)議，新一代TLS 協(xié)議1.3 版本的安全性和高速性得到很大提高[5-7]。TLS1.3 協(xié)議采用高強度的加密及認證機制實現(xiàn)了信息的安全防護。

由于主流安全協(xié)議的復雜性和處理開銷，無法更好地應(yīng)用于智能電表。該文從電力系統(tǒng)基礎(chǔ)設(shè)施、電表所用芯片性能、成本及通信安全強度等方面進行綜合考慮，在傳統(tǒng)智能電表通信網(wǎng)絡(luò)協(xié)議棧中嵌入TLS1.3 協(xié)議，設(shè)計了一套TLS1.3 協(xié)議在電表上的應(yīng)用方案，實現(xiàn)電表的高強度安全通信，使電表更好地融入智能電網(wǎng)。

1 電表安全協(xié)議需求

當前智能電表愈加智能化和網(wǎng)絡(luò)化，多數(shù)已知的安全漏洞都與通信媒介及協(xié)議相關(guān)[8-9]。電表作為電力信息采集的計量設(shè)備，一般采用RS485串口通信協(xié)議或其他方式連接終端設(shè)備，基于電表在智能電網(wǎng)中的實際應(yīng)用，從以下方面分析電表安全協(xié)議需求。

1.1 電表響應(yīng)時間

基于電表硬件性能的限制，在電表與主站系統(tǒng)的信息處理方面存在一定的不足，其業(yè)務(wù)處理能力受制于電表采用的微控制單元MCU 的性能。TLS1.3協(xié)議涉及密鑰協(xié)商、數(shù)字簽名、簽名驗證、公鑰生成等算法[10-11]。在電表上采用TLS1.3 協(xié)議，需要考慮電表運行安全協(xié)議的速度，即電表對主站系統(tǒng)的響應(yīng)時間。電表需要按規(guī)定時間響應(yīng)主站系統(tǒng)的消息請求，當電表選擇運行不同的密碼套件、橢圓曲線類型或者握手子消息時，電表耗時差距很大，若電表MCU 主頻較低時，TLS1.3 握手耗時長，可能出現(xiàn)超時處理，造成網(wǎng)絡(luò)連接失敗等。TLS1.3 協(xié)議在智能電表中的處理流程如圖1 所示。

圖1 TLS1.3協(xié)議在智能電表中的處理流程

1.2 安全強度

安全強度高的加密算法對電表MCU 的計算性能要求高。若MCU 主頻較低，電表使用復雜的安全算法，雖然安全強度更高，但加密運算時間過長，無法及時應(yīng)答主站，將會導致網(wǎng)絡(luò)癱瘓等后果。方案基于電表MCU 性能，選擇合適的TLS1.3 加密套件，結(jié)合TLS1.3 協(xié)議子消息的設(shè)計，使電表在保證傳輸安全的同時，及時響應(yīng)主站請求。TLS1.3 協(xié)議根據(jù)已發(fā)生的攻擊行為，刪除了一些不安全的加密算法[12-14]。支持的加密套件，每個都有明顯的優(yōu)勢，智能電表可根據(jù)算法的安全強度和硬件資源進行選擇。方案選擇密碼套件的依據(jù)如下：

1）AES_128_CCM_8_SHA256 密碼套件。CCM模式的標準認證標簽為16 個字節(jié)，CCM_8 模式的密碼套件將標簽減少到8 個字節(jié)，從而節(jié)省了8 個字節(jié)的開銷，但代價是更高的偽造概率。

2）若電表支持加密和認證硬件加速，優(yōu)先選擇AES_128_GCM_SHA256 加密套件，安全強度高且運算速度快。若電表只支持AES 硬件加速，優(yōu)先選擇TLS1.3 加密套件AES_128_CCM_SHA256，CCM 模式?jīng)]有GCM 模式的輸入大小限制，比GCM模式更容易實現(xiàn)。

3）智能電表若沒有硬件加速資源，加密和認證算法采用純軟件來實現(xiàn)，AEC_GCM/CCM 算法運算速度慢，優(yōu)先選擇CHACHA20_POLY1305_SHA256套件。

4）若電表采用性能較高的MCU，追求更高的安全強度，可以選擇TLS1.3 協(xié)議加密套件AES_256_GCM_SHA384，對于Grover 算法攻擊有更高的抵抗力，可以使電表通信更加安全，但提高了成本，且對電表要求較高。

2 基于TLS1.3協(xié)議的應(yīng)用方案

2.1 整體思路設(shè)計

TLS1.3 標準協(xié)議較為復雜，由握手協(xié)議和記錄協(xié)議組成[15-16]。握手協(xié)議旨在通過認證密鑰交換機制來協(xié)商密鑰,負責電表與集中器協(xié)商會話狀態(tài)的密鑰參數(shù)。為了提高該電表安全方案的拓展性、復用性和靈活性，著重設(shè)計了TLS1.3 的握手協(xié)議。握手協(xié)議由眾多子消息組成，可根據(jù)實際應(yīng)用進行裁剪。記錄協(xié)議負責加解密及封裝數(shù)據(jù)，可依據(jù)協(xié)議標準進行設(shè)計，此處不做贅述。該方案的電表握手過程如圖2 所示。

圖2 電表握手流程

握手步驟可總結(jié)如下：

1）為與終端設(shè)備GateWay 密鑰進行協(xié)商，智能電表解析了ClientHello 數(shù)據(jù)幀。ClientHello 數(shù)據(jù)幀中擴展extension 還會帶有supported_groups 擴展，這個擴展表明了GateWay 支持的用于密鑰交換的命名組，按照優(yōu)先級從高到低，電表按照支持組件supported_groups 中得到的匹配項，匹配共享密鑰key_share擴展中的類型。電表選擇GateWay支持的橢圓曲線類型，使用橢圓曲線的基點計算電表的公鑰。

2）電表提取ClientHello 中的key_share 擴展對應(yīng)的公鑰，計算主秘鑰放在ServerHello 的key_share 擴展中，密鑰協(xié)商計算完成后，電表以ServerHello 作為響應(yīng)數(shù)據(jù)幀，向GateWay 傳輸電表協(xié)商成功的相關(guān)信息。該方案禁止電表重協(xié)商，若電表完成協(xié)商后又收到ClientHello 數(shù)據(jù)幀，將立即告警并斷開連接。電表TLS1.3 握手協(xié)議中，ServerHello 需要攜帶supproted_versions 擴展，且包含自己supproted_versions 中選擇的TLS 協(xié)議版本號。電表不作降級處理，GateWay 請求TLS1.3 協(xié)議連接，則電表以TLS1.3 協(xié)議響應(yīng)，否則將斷開連接。

3）在該方案中，電表從ClientHello 數(shù)據(jù)幀中獲得密鑰協(xié)商的相關(guān)信息，結(jié)合電表參數(shù)，完成橢圓曲線密鑰協(xié)商，之后將使用握手層密鑰加密握手信息。為保證電表的擴展信息安全，可將一些重要的協(xié)商參數(shù)放在加密擴展EncrypytedExtensions 幀中進行傳輸，但影響握手速度，增加了系統(tǒng)開銷，因此可設(shè)置為空。

4）方案采用證書進行雙向認證，為了加快身份認證，當電表向GateWay 發(fā)送證書請求消息時，同時從EEPROM 讀取自己的證書并發(fā)送。該方式避免GateWay 向電表發(fā)送證書請求，減少設(shè)備認證耗時。

5）為防止上述信息被篡改，電表對之前的握手數(shù)據(jù)進行計算簽名，并通過Certificate Verify 數(shù)據(jù)幀發(fā)送。該消息必須在Certificate 消息之后、Finished消息之前發(fā)送。

6）電表發(fā)送Finished 數(shù)據(jù)幀作為電表身份認證階段的最后一條信息。若GateWay 通過驗證電表的Certificate Verify 數(shù)據(jù)幀和Finished 數(shù)據(jù)幀，將發(fā)送應(yīng)用層數(shù)據(jù)。

7）若終端驗證電表證書成功，將響應(yīng)電表的請求并發(fā)送證書。電表驗證證書和Finished 數(shù)據(jù)幀成功后，握手完成。智能電表導出記錄層所需的密鑰材料，以交換通過認證加密保護的應(yīng)用層數(shù)據(jù)。

2.2 擴展選項協(xié)商

GateWay基于主站系統(tǒng)組網(wǎng)要求，發(fā)送TLS1.3協(xié)議握手請求，為了與電表協(xié)商握手信息，ClientHello數(shù)據(jù)幀將攜帶大量的擴展信息。智能電表收到ClientHello 消息后，按照次序逐個解析擴展信息，依據(jù)電表的需求，處理并響應(yīng)相關(guān)擴展，其余擴展為了降低電表開銷而不作處理。

基于該方案設(shè)計的TLS1.3 握手流程，電表須響應(yīng)的擴展類型信息如表1 所示，選擇響應(yīng)的擴展信息并作出響應(yīng)。

表1 電表擴展信息類型

2.3 電表雙向認證

基于PKI 體系的證書認證方式無法適用于電力基礎(chǔ)設(shè)施薄弱的地區(qū)，如公司某海外項目。為了使電表完成TLS1.3 協(xié)議中的設(shè)備認證，在一定程度上簡化了電表認證實現(xiàn)的復雜度。電表建立通信時，執(zhí)行證書初始化，通過密鑰協(xié)商生成加密密鑰，主站系統(tǒng)向電表傳輸電表和GateWay 的兩張證書及其對應(yīng)私鑰，電表解密成功并寫入EEPROM。在證書預(yù)裝過程中使用通信開銷較低的對稱加密和哈希函數(shù)，證書初始化完成后，電表與GateWay 進行TLS1.3 連接。

為降低系統(tǒng)開銷，電表在TLS1.3 握手雙向認證時，不完全解析GateWay 發(fā)送的證書，只與預(yù)裝的GateWay 證書作比較，若一致則認證成功。

3 方案應(yīng)用及性能分析

3.1 電表應(yīng)用案例

該方案已用于公司項目，電表所用MCU 為FM33A048，主頻最高達40 MHz，RAM 容量為32 kB，電表應(yīng)用層為SML 協(xié)議，自動抄表系統(tǒng)底層通信協(xié)議為鏈路層。電表所用的MCU 性能較低。安全方案應(yīng)用于項目的關(guān)鍵信息如下：

1）在保證安全強度的前提下，電表選擇支持TLS1.3 協(xié)議AES_128_GCM_SHA256 加密套件和CHACHA20_POLY1305_SHA256套件，為減少電表與GateWay建立TLS1.3握手的耗時，電表執(zhí)行TLS1.3密鑰協(xié)商，優(yōu)先選擇CHACHA20_POLY1305_SHA256加密套件。

2）智能電表支持的曲線類型：secp256r1、secp384r1、BrainpoolP384r1?？筛鶕?jù)客戶方的電網(wǎng)需求進行選擇。

3）電表對收到的證書未全面解析，只將其中的公鑰取出，未作抄表客戶端證書驗證，只與證書初始化中傳遞過來的SGW 證書作比較。

4）智能電表的數(shù)據(jù)流采用內(nèi)存復用方案，即采用應(yīng)用層SML、TLS 層、物理層HDLC 三層數(shù)據(jù)流共用一個空間的形式來減少內(nèi)存空間的使用，電表應(yīng)用層將數(shù)據(jù)放入數(shù)據(jù)流時，根據(jù)TLS1.3 握手協(xié)商出的安全套件預(yù)留出不同的TLS1.3 頭尾空間，以便TLS 層進行應(yīng)用層數(shù)據(jù)加密。

3.2 性能分析

該電表安全方案采用純軟件來實現(xiàn)，TLS1.3協(xié)議中的ECC 算法運算量大、耗時較長，算法中使用不同類型的橢圓曲線，通過涉及的Compute Shared Secret、Key Generation、Public Key Validation、Signature Generation 和Signature Verification 算法運行過程耗時來體現(xiàn)，為了使電表及時響應(yīng)和減少所需空間，通過調(diào)整window size、編譯器優(yōu)化等級和ECC 算法單次執(zhí)行比特位stepNum 的大小，測試電表的最佳運行狀態(tài)。

算法性能與密鑰長度關(guān)系很大，由表2 中的信息分析可得，簽名驗證算法在電表運行中耗時最長，使用橢圓曲線BrainpoolP384r1 簽名驗證平均耗時約20 s。根據(jù)主站系統(tǒng)的響應(yīng)時間要求選擇ECC 曲線類型。

表2 windows size=2電表耗時

為了使電表運行在最佳狀態(tài)，須確定ECC算法中滑動窗口的大小，以TLS1.3 協(xié)議Signature Generation算法為例進行說明，簽名使用的橢圓曲線類型為BrainpoolP384r1，其他測試環(huán)境變量不變。由表2 和表3 的數(shù)據(jù)進行分析，相比電表在windows size=4，單次執(zhí)行k的位數(shù)stepNum=10 的運行環(huán)境下，當選擇的windows size=2 時，單次運行算法平均耗時增加約0.89 s，TLS1.3 總體握手協(xié)議運行時間增加約為10 s，但優(yōu)勢是空間節(jié)省了0.87 kB。

表3 windows size=4電表耗時

綜上所述，電表密鑰協(xié)商、簽名生成及驗證使用NIST P-256(secp256r1)、NIST P-384 (secp384r1)和BrainpoolP384r1 三條曲線進行測試。在本公司的項目中，滑動窗口大小設(shè)置為4 bit。編譯器IAR 開啟高級優(yōu)化，經(jīng)過批量測試，程序運行穩(wěn)定；ECC 算法標量乘單次執(zhí)行比特位StepNum 為10 bit，執(zhí)行結(jié)束退出ECC 運算，并保存當前運算數(shù)據(jù)，在其他任務(wù)完成后再次進入退出時的斷點繼續(xù)進行運算，該數(shù)值依據(jù)MCU 的主頻進行設(shè)置，若主頻較高，可以增大單次執(zhí)行比特位。經(jīng)過長期大量測試，電表運行穩(wěn)定。

4 結(jié)束語

在電網(wǎng)的建設(shè)中，接入大量性能各異的智能電表，隨著電力公司對電表通信安全的要求不斷提高，某些海外地區(qū)要求電表升級支持TLS1.3 協(xié)議，以對抗網(wǎng)絡(luò)攻擊。由于TLS1.3 協(xié)議龐大復雜，一些智能電表因節(jié)省成本而采用低端且無硬件加密的芯片，處理速度及硬件資源成為實施TLS1.3 協(xié)議的瓶頸。因此，該文對TLS1.3 協(xié)議進行二次開發(fā)，在安全強度、公私鑰尺寸和計算速度等方面作出平衡，在電表上以純軟件實現(xiàn)TLS1.3 協(xié)議，設(shè)計TLS1.3 握手協(xié)議和認證機制以兼容現(xiàn)有的電力基礎(chǔ)設(shè)施。該方案已用于德國智能電表，結(jié)果表明其滿足實際安全需求，電表接入當?shù)刂悄茈娋W(wǎng)安全、穩(wěn)定。