工業技術研究院 資訊與通訊研究所 陳宣同
行政院大力推動「智慧電網總體規劃方案」之下，越來越多的智慧電網設備開始上線運作，由於智慧電網設備的一大特點就是網路遠端控管，但智慧電網設備遍布全台各地，勢必無法為這些設備提供專網專用的安全保護，相關設備均須直接面對來自網際網路的威脅，因此需要安全且更有效率的管理方式，相比於傳統的對稱式金鑰管理系統，運用公開金鑰基礎建設（Public Key Infrastructure, PKI）的資訊安全系統，除了不必在伺服器端存放大量的設備金鑰外，亦可提供更多樣化的資訊安全應用情境，如數位簽章、身分授權、來源認證等等。
雖然公開金鑰基礎建設已在網際網路上廣泛使用，但其主要的用途是讓網際網路的網站單方面的向客戶端證明自己的身分，因此不論是在使用環境以及安全目標均和智慧電網的需求有所差異，要如何在智慧電網上利用公開金鑰基礎建設來提升電網安全性，KPI架構正是達到目標的關鍵技術。
智慧電網並不是一個全新的概念，至今已有十多年的發展歷史，而在談智慧電網之前，得先知道電力系統的基本架構。電力系統基本可分為三大區塊，亦即發電端、輸配電端、用（售）電端，套用在智慧電網上則如圖1所示。在過去，傳統電網並不具備各式各樣先進的感測器，相關監測結果亦無法快速的彙整統計分析，可以說是既「瞎」又「啞」，看不到精細的狀態變化，也無法把收集到的資訊大聲講出來。常常都要等到用戶回饋相關災情才知道出事了。而在智慧電網架構中，則透過廣泛部署感測器，且相關感測數據亦可透過通訊網路即時性的回傳電力控制中心，實現了即時監控、測試，甚至可遠端對斷點設備進行修復或移除，或是重新對電力系統配置新路由，以繞過故障點設備。
智慧電網介紹
而對用戶來說，最大的感受則是導入智慧電表基礎建設（Advanced Metering Infrastructure, AMI）後，隨著帶有通訊功能的電表進入到家庭內，用戶可更直觀的掌握自己的用電行為，甚至配合各項節電措施來達到降低電費開支的目的。 而在發電端的部分，除了傳統的大型發電設施外，隨著各式綠色能源的崛起，以及電力市場自由化的影響，電力來源也變得多樣化且繁雜，各式發電設備要如何協調尖峰離峰的發電量，也都必須仰賴智慧電網的即時處理能力。
然而，智慧電網在藉由通訊網路帶給大家便利與快捷的同時，也同時遭遇了來自通訊網路的資安威脅，甚至有可能出現電影中電網被不法份子掌控的情節，因此相關的存取權限控管就變成炙手可熱的議題了。
圖1 智慧電網基本架構
智慧電網上的公開金鑰基礎建設
隨著密碼學技術的演進，相關安全標準也在不斷的推陳出新，以AMI相關國際標準來看，DLMS也在2014年推出了Green Book Ed.8[1]，用以取代他們在2009年發行的Green Book Ed.7[2]，其中最主要的變化為導入了非對稱式（公開金鑰）演算法的使用；而IEC也在2017年最新版的IEC 62056-5-3:2017[3]中導入了Green Book Ed.8.2[4]，等同於也導入了非對稱式演算法；此外在IEC 62351-9:2017[5]中，也用大量的篇幅講述了以非對稱式演算法為基礎的公開金鑰管理系統。由上述例子來看，智慧電網導入公開金鑰基礎建設不僅僅處於理論研究階段，而是一個國際趨勢了。
因此，接下來我們將介紹智慧電網上的公開金鑰基礎建設，但在此之前，我們先來探討其前身，也就是傳統的對稱式金鑰管理架構，接著再介紹公開金鑰基礎建設。
對稱式金鑰管理架構
顧名思義，對稱式金鑰管理架構其核心概念即是使用對稱式金鑰演算法來進行存取權限控管，以AMI的應用情境來看，所有的智慧電表均需配發獨立的對稱式金鑰，且該金鑰除了儲存在智慧電表內，還需要儲存在控制中心的金鑰管理系統（Key Management System, KMS）之內，也就是說控制中心需維護一個龐大的金鑰資料庫保存所有智慧電表的金鑰。
且採用對稱式金鑰演算法僅能確保訊息傳遞的機密性，並無法提供訊息的不可否認性，也就是說相關訊息並無法提供第三方驗證其來源，發送端可否認其曾經發送過該訊息；在金鑰部署方面亦須對每一顆智慧電表進行離線且獨立的金鑰安裝作業。而對於存取權限控管方面，若要中止已釋出之存取權限，僅能夠對智慧電表進行金鑰更新作業。以上種種限制，對於多樣化的智慧電網應用情境以及日益複雜的網路攻擊手法，漸漸變得不勝負荷，因此進一步的導入公開金鑰基礎建設是有其必要性與急迫性的。
公開金鑰基礎建設
公開金鑰基礎建設是以公開金鑰密碼學（又稱為非對稱式密碼學）為基礎所衍伸出來的架構，由主管單位、使用單位、使用者、政策、硬體、軟體、執行程序等單元組成，一切操作都是圍繞在使用公開金鑰密碼學簽署的數位憑證，大致上可分為憑證的管理以及憑證的使用。憑證的管理包含了憑證的請求、簽署、發放、驗證、更新、廢止，憑證的使用則是藉由憑證內含的公開金鑰來進行文件簽署、身分認證、金鑰交換、加密通道建立等操作，在本文接下來的篇幅中，我們將著重在憑證的管理技術上進行介紹。有關對稱式與非對稱式密碼學之比較可參照表1。
表1 稱式 vs 非對稱式
在傳統資安領域上，網絡安全主要是在解決機密性、完整性和可用性（Confidentiality、Integrity、Availability，CIA）的議題，但是對於電力系統的應用情境來說，電力系統的持續安全和可靠運行才是重中之重。因此在智慧電網中，反倒更看重於：資料來源驗證、訪問授權和完整性保護，而機密性和不可否認性僅有少數應用情境才會有所著墨。
智慧電網憑證管理
公開金鑰基礎建設成員介紹
整體智慧電網之PKI主要架構大致如圖2所示。
圖2 智慧電網之PKI主要架構
1.註冊管理中心（Registration Authority, RA）
在基於PKI的系統中，首先要求成員通過RA證明其身分。對於人員，RA可以藉由證件、護照或其他官方文件來確定個人身分。對於系統和設備，RA可以通過製造商頒發的數位憑證或唯一的一次性密碼（one-time-password, OTP）來確認其身分。
2.憑證管理中心（Certification Authority, CA）
確認身分之後，系統或設備需要由CA頒發證書，製造商先幫其產生證書簽名請求（Certificate Signing Request, CSR），並對該CSR產生數位簽章。CA驗證CSR並根據CSR中包含的資料頒發數位憑證。CA除了可以由內部成員來擔任，也可以由外部公開可信任的第三方來擔任。而第三方CA在頒發憑證前則需要額外的信任機制來確認新成員的有效身分，可以由人員的親自驗證或將透過已驗證的數位憑證來換發新的數位憑證。
3.目錄服務
目錄服務除提供外界目錄查詢服務，如憑證及憑證廢止清冊之公布，並提供憑證廢止訊息、新版、舊版憑證實作準則之查詢及憑證相關軟體下載等服務。
4.Sub-CA
對於整體應用情境來說，需要管理的Device其數量可能為數不少，而其所在地也可能差異甚大，兼且為了降低Root CA之運算及網路負擔，Root CA可能會尋找其代理人，也就是Sub-CA，將其簽發憑證之權力授權給Sub-CA，再由 Sub-CA去簽發下層設備的憑證。而驗證下層Device的憑證時則是先確認其憑證之簽發者是誰也就是Sub-CA，接著再去驗證Sub-CA的憑證之合法性即可。
5.Factory
Factory之作用與Sub-CA類似，其主要是負責生產Device，同時在生產過程中，發放出廠憑證給Device，而Device出廠憑證中所包含的公鑰及其對應的私鑰，可由Factory一併產生再寫入Device中，或是由Device自行產生公司鑰配對，再將其公鑰交由Factory簽署成憑證並寫入Device中。
6.Device
Device在出廠時，將會由Factory預先安裝一組由Factory為其簽署之專屬出廠憑證，但此憑證僅用來供Sub-CA驗證其是由Factory所生產，並無法用於正式上線所需之連線服務，而當Device要正式上線運作時，Sub-CA將在驗證完其身分後，頒發一組正式憑證給Device，以供其後續正式上線運作所需。
智慧電網PKI建議採用之通訊協定
此處的通訊協定指的是進行憑證管理所需要的訊息交換方式。 以下將簡單介紹相關步驟所建議採用的通訊協定
1.Trust Anchor Management Protocol（TAMP）
RFC 5934[6]中定義的TAMP適用於管理可信任憑證庫的通訊協定，該協定利用了加密訊息語法（Cryptographic Message Syntax, CMS）提供資料完整性和資料來源身分驗證。可信任憑證庫可以包含標準CA證書、未簽名的CA證書或RFC 5914[7]定義的TrustAnchorInfo物件。
2.Simple Certificate Enrolment Protocol（SCEP）
SCEP主要是為了簡化大量設備的註冊流程，並使數位憑證的發行和註銷具有更高的彈性，憑證簽署請求端可以在HTTP上使用SCEP來傳遞基於PKCS＃7[8]和PKCS＃10[9]的憑證簽署請求。SCEP由IETF在nourse-scep-23草案[10]中所定義。而基於對PKCS＃7的依賴性，SCEP現階段僅支援RSA演算法。
3.Internet X.509 PKI Certificate Management Protocol（CMP）
CMP是用於在PKI中獲取公鑰證書的網際網路協定，它定義了客戶端和PKI成員之間的訊息交換方式。與SCEP相比，它提供了更多選項，但也更加複雜，除了憑證撤銷清單（Certificate Revocation List, CRL）檢索、憑證請求管理、請求者的識別以及相關私鑰的擁有證明之外，CMP還提供了更多其他的功能，比如憑證機構間交互認證和必備的憑證撤銷功能。完整的CMP定義請參照RFC 4210[11].
4.Enrolment over Secure Transport（EST）
在EST中，只有簡單的PKI請求／回覆互動是必選性的，而完整的過程支持則是可選的。從EST提供的功能來看，EST可以看作是SCEP的改良版，EST限定CSR訊息必須使用傳輸層安全性協定（Transport Layer Security, TLS）來建構安全通道，並利用TLS通道的身分驗證來識別和認證請求者。除證書註冊和管理功能外，EST還允許管理設備上的可信任憑證庫，這也允許了更新CA證書和相應的信任鏈。完整的EST定義請參照RFC 7030[12]。
5.Online certificate status protocol（OCSP）
在RFC 6960[13]定義的OCSP是在檢查公鑰證書的撤銷狀態時，用來替代CRL檢索的方法。如果憑證驗證端擔心某個特定的憑證是否仍然有效，則可以將OCSP撤銷狀態請求發送給負責該證書狀態的OCSP服務器（或CA）。為了避免重送攻擊（Replay Attack），過程中必須使用”nonce”（一次性值）將此次憑證狀態請求與任何先前的憑證狀態請求區分開來。接著，OCSP回覆者將查詢證書最新狀態並回覆「良好」、「已撤銷」或「未知」，且其回覆的訊息須使用其自己的私鑰來進行簽署以避免偽造 。
通常，成員與OCSP回覆者之間需要保持連線狀態，以傳輸OCSP請求和OCSP回覆。然而，對於智慧電網現場中的某些設備而言，持續保持網路連線狀態是一項沉重的負擔。此外，對於某些智慧電網設備而言，可能不具備處理OCSP回覆的能力，且由於OCSP不會主動發出未經請求的憑證狀態更新，即便憑證狀態檢查後不久便撤銷了證書，所以OCSP響應的有效期也應較短。
因此，根據智慧電網網路配置和設備的功能需求，可能可以架設一台憑證狀態代理伺服器，以使用CRL和OCSP的混合組合。該代理伺服器在特定時間段內（例如每小時或24小時內）獲取CRL，然後轉為OCSP服務，以回覆周邊電網設備的OCSP請求。
結語
雖然PKI已有20多年的歷史，但對於智慧電網來說可說是一個新的突破。現階段智慧電網安全性的提升主要還是著重在售電端的AMI相關系統，如DLMS就很明確的在其green book 8th [1]中將安全性層級分為對稱式為主的security suite 0，以及導入公開金鑰演算法的security suite 1&2，同時本團隊也正將過去使用之DLMS電表系統升級至security suite 1&2。因此在PKI兩大區塊中，憑證應用已有初步的成果，而剩餘的憑證管理即是本文所探討的主題，同時也是本團隊未來發展的重點項目，相信藉由智慧電表的成功經驗，可將相關成果擴及整體智慧電網的應用。
參考文獻
[1] DLMS User Association, “DLMS/COSEM Architecture and Protocols”, Green Book Edition 8, 2014.
[2] DLMS User Association, “DLMS/COSEM Architecture and Protocols”, Green Book Edition 7, 2009.
[3] Electricity metering data exchange – The DLMS/COSEM suite – Part 5-3: DLMS/COSEM application layer, IEC 62056-5-3, IEC, 2017.
[4] DLMS User Association, “DLMS/COSEM Architecture and Protocols”, Green Book Edition 8.2, 2016.
[5] Power systems management and associated information exchange, Data and communications security, Part 9: Cyber security key management for power system equipment, IEC 62351-9, IEC, 2017.
[6] Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Management Protocol (TAMP)”, RFC 5934, DOI 10.17487/RFC5934, August 2010, <https://www.rfc-editor.org/info/rfc5934>.
[7] Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Format”, RFC 5914, DOI 10.17487/RFC5914, June 2010, <https://www.rfc-editor.org/info/rfc5914>.
[8] Kaliski, B., “PKCS #7: Cryptographic Message Syntax Version 1.5”, RFC 2315, DOI 10.17487/RFC2315, March 1998, <https://www.rfc-editor.org/info/rfc2315>.
[9] Nystrom, M. and B. Kaliski, “PKCS #10: Certification Request Syntax Specification Version 1.7″, RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>.
[10] M. Pritikin, Ed., A. Nourse, and J. Vilhuber, ” Simple Certificate Enrollment Protocol”, draft-nourse-scep-23, September, 2011.
[11] Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)”, RFC 4210, DOI 10.17487/RFC4210, September 2005, <https://www.rfc-editor.org/info/rfc4210>.
[12] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., “Enrollment over Secure Transport”, RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[13] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”, RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
