header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
掃碼下載APP
Partnered With:

科普:保護驗證者密鑰的幾種方法

閱讀本文需 29 分鐘
本文提供了多種方法來保護驗證者密鑰,同時確保它們可以用來履行驗證職責。

原文標題:《科普 | 保護驗證者密鑰的幾種方法》

原文來源:以太坊愛好者



我們預設讀者對驗證者有最基本的瞭解,包括但不限於「驗證者是什麼」,「他們爲什麼需要密鑰」,以及「他們通常需要什麼操作」等概念。

什麼是驗證者密鑰?


在 ETH 2.0 中,驗證者密鑰被用來確定相關消息是哪位驗證者發出的。驗證者要發送這些消息才能獲得獎勵(並避免遭受懲罰)。

驗證者密鑰的風險很難衡量:驗證者密鑰本身無法用來訪問資產。因此,即使攻擊者獲得了你的驗證者密鑰,也無法直接盜取資產。但是,他們可以通過敲詐勒索 1 等方式間接獲利,更有甚者,比起自己獲利,他們更想讓你蒙受損失 2。因此,我們通常認爲驗證者密鑰的安全需求很高。





- 圖 1 :驗證者的安全需求 -

但是,不像取款密鑰那樣(你可以離線保存起來),驗證者密鑰要能夠隨取隨用,因爲驗證者在每個 epoch(大約 6.5 分鐘)都要簽署多個消息。因此,驗證者密鑰的訪問需求也很高。


- 圖 2 :驗證者密鑰的訪問需求 -

因此,我們發現自己陷入了兩難困境:從傳統上來說,同時滿足安全性和可訪問性需求是很難實現的,因爲提高安全性往往會降低可訪問性,反之亦然。


- 圖 3 :驗證者密鑰的雙重需求 -

爲滿足對安全性和可訪問性的雙重需求,我們需要採取更高級的措施,在不作重大妥協的前提 下,較高程度地滿足這兩方面的需求。這可以通過分層來實現。本文的目的是探究每一層所提供的功能,並瞭解哪些功能適用於或不適用於驗證者設置。

Eth2 中的密鑰對都有一把公鑰和一把私鑰。出於本文的寫作目的,全篇所用的「key(密鑰)」一詞指代的都是通常叫做私鑰的那把;如果指代的是公鑰,會有明確的說明。

(譯者注:validator key 和 withdrawel key 都是密鑰對,都分公鑰和私鑰。公鑰是用來在 Eth1 鏈上註冊的,可公開;私鑰則是驗證者自己實際使用的,不可公開,公開則自己的資產和驗證者都完全被他人掌控了。)

目標和分層


首先,我們需要定義攻擊者和用戶的目標。在知道爲什麼要保護驗證者密鑰之後,我們就可以思考每個功能可以在多大程度上實現這一目標。首先,攻擊者的目標可以被定義成:


攻擊者的目標是,簽署某一條消息時能簽出與目標驗證者公鑰相對應的簽名(即能僞造驗證者對某一條消息的簽名)。

當然了,如果這是唯一的目標,那麼直接毀掉驗證者密鑰就能阻止攻擊者了。但是,這對用戶來說一點幫助也沒有。因此,我們需要考慮的第二個目標,也就是用戶的目標,可以被定義成:

用戶的目標是隻簽署理想消息,不簽署不良消息。

就本文的目標而言,理想消息指的是能夠獲得獎勵的消息,不良消息指的是會觸發 罰沒事件 3 的消息。

請注意,攻擊者要想實現其目標,只需要簽署任意一條消息即可,而用戶的目標是持續性的。這種不對稱性是安全系統的一大特徵,即,攻擊者只需贏一次就夠了,而用戶需要每次都贏。

爲此,我們需要一個由不同分層或者說獨立功能組成的系統,提供增強型安全性或增強型可訪問性,而且可以將二者結合起來,共同達到較高水平。一個良好的安全模型需要具備多個分層,每個分層都會(單獨或與其它分層結合起來)提供某種保障或其它分層的備份,並且有足夠多的分層提供可訪問性,從而確保用戶的目標可以實現。請注意,本文聚焦於技術保護:其它層面(例如,操作層面和社會層面)上的安全性都不屬於本文的討論範圍內,雖然它們在任何安全模型中都是至關重要的部分,應該採取相應解決方案。

分層


爲了探討驗證者密鑰的保護方式,我們先來做個簡單的演示:



- 圖 4 :驗證者密鑰 -

與 ETH 2.0 的所有密鑰一樣,驗證者密鑰也是一串數字 4。如果驗證者在不採取任何保護措施的情況下存儲了驗證者密鑰,攻擊者很容易就能獲得該密鑰並實現其目標。以下幾類人能夠獲得驗證者密鑰:

- 任何有權訪問運行驗證者客戶端的計算機賬號的人

- 任何被授權訪問運行驗證者客戶端的計算機的人

- 任何可以物理訪問運行驗證者客戶端的計算機的人

- 任何有權訪問運行驗證者客戶端的計算機的數據的人(例如,備份數據)

這樣一來,用戶就無法實現其目標(即,不簽署不良消息)。因此,我們首先要通過加密的方式來保護驗證者密鑰:



- 圖 5 :加密驗證者密鑰 -

我們可以通過多種方式加密驗證者密鑰,例如,EIP-2335 標準 5。一旦驗證者密鑰被加密,除非攻擊者掌握加密口令(passphrase),否則無法解密出密鑰 6。這樣就可以很好地保護驗證者密鑰(無論是將它存儲在驗證者客戶端還是數據備份內)。

乍看之下,攻擊者似乎無法通過任何方式來實現其目標。然而,用戶也沒有辦法實現其目標,因爲他們再也無法簽署理想消息:無論是對於用戶還是攻擊者來說,經過加密的密鑰都是沒用的,因爲用戶必須先將該密鑰解密,然後才能用它來簽署消息。這樣一來,驗證者進程就一定要包含訪問解密口令這一步驟。即然驗證者進程可以訪問解密口令,那麼攻擊者也可以訪問該口令,尤其是在解密口令被存儲在驗證者客戶端的情況下,因爲驗證者客戶端有可能遭到攻擊。

因此,這種改變本身不算上策。不過,如果我們將它與第二層結合起來,就能提供更有力的保護:



- 圖 6 :遠程口令 -

如果解密口令是遠程存儲的,加密驗證者密鑰會帶來更強大的保護 7。由於口令不再存儲於驗證者客戶端內,攻擊者無法從磁盤數據中獲得未加密的私鑰。攻擊者只能發動更加複雜的攻擊,例如,從內存中獲取解密後的密鑰,或模仿驗證者客戶端進程來獲得解密密鑰。

雖然攻擊難度更大了,但是複雜攻擊依然有可能獲得驗證者密鑰。此外,用戶依然可能在不經意間簽署不良消息。因此,我們可以通過增加一個遠程簽名器層來爲用戶提高安全性和可訪問性。


- 圖 7 :遠程簽名器 -

遠程簽名器分離了驗證者客戶端的核心功能:確定要放到消息中的數據、簽署消息並將該消息發送至 ETH 2.0 網絡。第一個和第三個功能仍保留在驗證者客戶端手中,第二個功能由遠程簽名器來實現。遠程簽名器還引入了 罰沒保護機制,可以確定哪些是理想消息,哪些是不良消息,並予以簽署或拒絕。

如何阻止攻擊者將攻擊目標從驗證者客戶端轉移到遠程簽名器呢?首先,簽名器可以具備比驗證者客戶端更高的安全性。驗證者客戶端需要執行許多任務,包括與 ETH 2.0 網絡的其它組成部分(如信標節點)通信。這些通信可以爲攻擊者提供信息和攻擊界面。由於簽名器只與驗證者客戶端通信,它們的活動受到很多限制,這就爲雙方的服務器帶來了更高的安全性。

其次,遠程簽名器爲用戶帶來了其它好處。現在,同一個遠程簽名器可以與多個驗證者客戶端通信,使得我們能夠創建具備高可用性的驗證者客戶端基礎設施。遠程簽名器確保驗證者客戶端不會簽署任何不良消息。

然而,事實上,遠程簽名器存在單點故障問題:如果遠程簽名器遭到攻擊,或出現故障,用戶就連理想消息也簽名不了。有沒有一種方法可以讓遠程簽名器更能抵抗攻擊,同時又不會失去上述任一好處?


- 圖 8 :門限簽名 -

我們還可以在上述層次的基礎上再構建一層門限簽名,進一步增強安全性和可訪問性。驗證者密鑰需要用 Shamir 密鑰分割流程來處理,即,使用驗證者私鑰生成多個密鑰,然後將它們發送給遠程簽名器。


- 圖 9 :Shamir 密鑰分割 -

現在,每個遠程簽名器都持有由驗證者私鑰生成的密鑰了,而且只需幾個遠程簽名器就可以創建有效簽名,也就是所謂的 門限簽名(threshold signature)。假設有 3 個遠程簽名器,其中 2 個遠程簽名器提供個人簽名來生成一個聚合簽名,如下圖所示:


- 圖 10 :生成聚合簽名 -

門限簽名的表達式通常寫成 m/n,也就是說,假設總共有 n 個簽名,需要任意 m 個簽名來生成一個有效簽名。如果門限值是 2/3,那麼使用任意兩個簽名即可生成一個有效簽名。

引入門限簽名之後,即使有一個服務器 8 出故障,用戶也能簽署理想消息,而且也不會增加用戶無意間簽署不良消息的概率。鑑於硬件、軟件和操作失敗的可能性不可消除,門限簽名確實是一個具有抗逆性的驗證基礎設施應有的功能。

雖然門限簽名機制會帶來額外的安全性,但是它有兩大缺點。第一,分發密鑰並不能預防長期攻擊:假設門限值是 2/3,如果有一個簽名器反水,整個機制就會留下永久的漏洞,只要再有一個簽名器反水,攻擊者就可以達成目標。第二,攻擊者有可能在密鑰分發過程開始前搶先獲得該密鑰,從而導致整個機制喪失意義。分佈式密鑰生成可以一舉解決這兩個問題:


- 圖 11 :分佈式密鑰生成 -

分佈式密鑰生成是一個比較複雜的話題。具體的運作方式不在本文的討論範圍內。但是,我們會提供一個簡短的功能說明,來闡述它是如何克服簡單門限簽名的侷限性的。

在分佈式密鑰生成開始前,用戶先要決定門限值,例如 2/3。他們可以選擇 3 個遠程簽名器,並啓動生成過程。這 3 個遠程簽名器會通過密鑰管理器 9 生成自己的密鑰,不與用戶或其他任何一個簽名器共享,以及一些公共信息。將來自 3 個簽名器的公共信息結合起來就能創建出一個合成公鑰。


- 圖 12 :創建合成公鑰 -

只需 3 個簽名器中的任意 2 個即可生成簽名,類似簡單的門限簽名。


- 圖 13 :一組簽名器簽署消息 -

如果有一個簽名器不可用,例如,下線維護或遭到攻擊,還可以通過另外兩個簽名器生成簽名。


- 圖 14 :另一組簽名器簽署消息 -

可以看出,分佈式密鑰生成與簡單的門限簽名具備相同的優勢,可以避免最開始需要分發密鑰的風險。但是,一個簽名器被攻陷就會留下永久漏洞的問題仍然存在。那分佈式密鑰生成還有其它招數嗎?

有的,就是「密鑰更新」。密鑰更新就是毀掉現有密鑰,由每個簽名器重新生成新的密鑰。新生成的密鑰保留原有密鑰的特性,即,任意兩個密鑰可以結合起來生成一個有效簽名。新的密鑰與原有密鑰不具有相關性,因此無法通過原有密鑰計算出新的密鑰。


- 圖 15 :密鑰更新 -

如果有一個簽名器遭到攻擊,其它簽名器可以觸發密鑰更新。新舊密鑰無法結合起來生成一個有效簽名。這樣一來,被攻擊者盜走的密鑰就會變得毫無用處。


- 圖 16 :攻擊失敗-

密鑰更新可以多次執行,以防多個簽名器遭到攻擊。

其它需要考慮的要點


安全性是一個大概念。上文闡述了不同安全層的功能和優點,並沒有提出任何完美甚至最佳解決方案。就保護驗證者密鑰而言,我們還需考慮很多要點,例如:


硬件錢包


支持 BLS12-381 的硬件錢包預計很快就會上線。硬件錢包可以替代下層所使用的簡單磁盤存儲系統。但是這樣一來,我們可能無法引入分佈式密鑰生成之類的高級技術。


成本效益


凡是涉及安全性的方案都有可能爲了提高一點安全性而花費大量資金。每個用戶都需要決定自己想要防範的攻擊,及其願意爲此付出的代價。


遠程存儲驗證者密鑰


上文已經討論過了遠程口令存儲。但是,遠程存儲驗證者密鑰是否還會帶來其它優勢(還是正相反)?雖然它不會增強安全性,但是在出現硬件故障的情況下,它可以讓驗證者客戶端更快恢復,這點對於用戶來說非常有利。但是,遠程存儲也會帶來額外的風險,因爲我們必需正確配置遠程存儲,確保只有那些獲得許可的人能夠訪問密鑰。


備份驗證者密鑰


雖然本文聚焦於如何保護驗證者密鑰不受攻擊,但是實際上大多數驗證者密鑰丟失事件背後的原因都平平無奇。最常見的就是存儲密鑰的硬件丟失。用戶需要一個備份策略,而且他們需要知道的是,一旦攻擊者獲得了被備份的密鑰,ta 就能對任意消息簽出與驗證者公鑰相對應的簽名。我們應該採取適當的措施來確保攻擊者無法訪問已備份的驗證者密鑰。在理想情況下,這些密鑰最好完全脫機存儲,而且外人無法接觸其存儲設備。


多個驗證者密鑰


如果有多個驗證者密鑰,它們之間,或者與它們各自的取款密鑰之間是否應該具備什麼關係?例如,將多個驗證者密鑰備份成一個種子,這樣確實使用起來比較方便,但是不會帶來安全效益。用戶應該考慮是否想在任意階段單獨控制驗證者密鑰,再進行相應的計劃。


結論


本文提供了多種方法來保護驗證者密鑰,同時確保它們可以用來履行驗證職責。


每個用戶都應該考慮他們想要提供的安全級別,以及他們應該採取的措施。應當考慮的是,驗證者密鑰不控制資金,因此竊取驗證者密鑰的攻擊者無法直接獲得任何利益 10。

本文單純從技術層面上探究瞭如何保護驗證者密鑰。我們還應該考慮運營和社會安全需求。若想全面保護驗證者密鑰,就得考慮到所有這些方面。

或者,你可以使用提供這類功能的質押服務。在綜合考慮技術、風險和資金管理的情況下,Attestant 正在構建硬件、軟件和操作服務,以提供機構級的質押服務,讓你可以隨時控制自己的資金。

腳註

1. 「交出贖金,否則就讓你遭到罰沒。」

2. 通過「金手指攻擊(Goldfinger attack)」或者將適當規模的攻擊與 ETH 衍生品相結合,這可能會對攻擊者的財富產生間接影響。

3. 罰沒事件指的是,如果有驗證者對 ETH 2.0 網絡造成傷害,就會損失很大一部分質押物。

4. 其範圍在 1 和 52,435,875,175,126,190,479,447,740,508,185,965,837,690,552,500,527,637,822,603,658,699,938,581,184,512 之間。

5. 至文本截稿時,EIP-2335 標準仍處於起草階段,不過已經有很多 ETH 2.0 密鑰生成器在使用該標準。

6. 我們假設口令足夠強大,無法暴力破解。

7. 這個例子很好地體現了,如何將兩個層次結合起來提供更高的安全性。

8. 其它門限簽名的變體可以提高冗餘性。

9. 我們使用密鑰管理器一詞來指代那些除簽名之外還要執行更多操作的遠程服務器。

10. 還應該注意的是,潛在攻擊者並不一定知道這一事實。


原文鏈接:https://mp.weixin.qq.com



歡迎加入律動 BlockBeats 官方社群:

Telegram 訂閱群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方帳號:https://twitter.com/BlockBeatsAsia

举报 糾錯/舉報
選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交