多重簽名+癱瘓證明技術,你的比特幣將神聖不可侵犯

買賣虛擬貨幣
譯者前言:我們知道,在密碼貨幣世界,私鑰就代表著資產,而私鑰的遺忘或者遭竊,對於任何人來說都是毀滅性的,歷史上有很多人因為遺忘了私鑰而丟失了自己早期投資的密碼貨幣,有的甚至因此而痛失了價值數億的資產。
而關於私鑰安全的解決方案,一種是冷儲存,另一種則是多重簽名技術。本文則要探討多重簽名技術的應用。一般多籤技術分為兩類,一類是N-of-N,即需要所有私鑰持有者進行簽名才能使交易生效,這是令駭客最頭疼的,因為他需要同時攻破所有人的私鑰才能夠控制資產。而常用的N-of-N多籤方案有2-of-2,3-of-3。而另一類方案則是N-of-M (其中N小於M),即M個私鑰當中,至少有N個私鑰進行簽名,則交易可生效。這種方案也是幣圈公司常用的一類方案,最為常用的方案有2-of-3。
然而,這些多籤方案同時這也會引入很大的風險,例如其中某個私鑰丟失(某個持有者發生意外),或者某個私鑰持有者心生貪念而向其他持有者發出威脅時,那麼相關資產就會處於丟失危險,我們可以把這類無法動用資產的情況統一稱為癱瘓。而既要很好地防禦駭客的攻擊,又要預防無法動用資產的情況,這似乎成為了一個悖論。那到底有沒有解決辦法呢?

來自康奈爾大學的電腦科學教授Ari Juels(工作量證明機制提出者之一),康奈爾大學博士後Iddo Bentov, 康奈爾大學電腦科學博士生Fan Zhang,康奈爾大學電腦科學博士生Phil Daian共同提出了一種稱為癱瘓證明(Paralysis Proofs)的技術,這使得多重簽名方案又有了新的可能。


 以下為整合譯文(注:其中的“我們”,指康奈爾大學的研究者):

從埋藏於“金銀島”的黃金寶藏,到七枚失蹤的法貝熱彩蛋,丟失和被盜的寶藏,一直是傳說中的事情。然而,在比特幣的世界,這裡沒有公主、惡龍或者海盜,這裡也沒有太多的浪漫。財富的丟失,往往只是因為膝上型電腦上的私鑰遺失了,或者弄丟了自己列印或抄寫的帶有私鑰的紙條,又或者是遭到了駭客的洗劫。

金鑰管理在任何密碼系統中都是至關重要的。像比特幣和以太坊這樣的密碼貨幣也不例外。私鑰的丟失或被盜,可能是災難性的,而要很好地處理私鑰也是一件非常困難的事情。使用者需要保護他們的私鑰,以免受狡猾駭客的竊取,同時又要妥善地保護它們以防資產丟失。金鑰管理在商業情景下尤其具有挑戰性,通常沒有人會信任完全被控制的資源。

一般而言,我們會使用多重簽名(multisig)技術來管理密碼貨幣的私鑰,這是一種強大的方法,簡單說就是讓多個使用者分別保管一個私鑰,而要進行交易,就需要其中幾個私鑰進行簽名。這種金鑰分發的方式,也被稱為秘密共享。

我們則釋出了一篇論文,解決了一般秘密共享方案(尤其在密碼貨幣領域)存在的嚴重問題。我們將這個問題稱為癱瘓問題。

秘密分享如何導致癱瘓問題的發生?

幾個月前,一位熟人向我們提出了一個簡單,但非常有趣的問題,而它也是現實世界金鑰分發挑戰的一個很好的例子。

這位朋友(這裡化名為Richie)和他的兩位商業夥伴共享了大量比特幣的所有權。而他們自然不希望當中有任何一個人能夠把這些比特幣偷偷拿走。他們希望確保這些比特幣只有在所有人的同意下才能夠使用。有一個簡單的解決方案,對吧?他們可以使用3 of 3的多重簽名方案,然後三個人都需要簽名才能夠使用這些比特幣。問題似乎解決了!但真的是這樣嗎?

很顯然,故事到這裡並沒有結束。當然,Richie和他的合作伙伴也會擔心其中有人把私鑰給弄丟的情況。例如儲存金鑰的裝置可能會壞掉,金鑰也有可能被錯誤刪除,或者有人遭遇了一些非常不幸的情況(例如車禍),那麼其中一名合夥人的私鑰就會丟失。則最終的結果是所有的比特幣就完全丟失了!

這並不是唯一糟糕的場景,Richie和他的合作伙伴也可能對如何花這些錢有著不同的看法,而且也無法達成協議。更糟糕的是,假設其中有一位合夥人是惡意或貪婪的,她可能透過扣留她的金鑰部分,來勒索其他人(換取資金)。在這種情況下,比特幣也可能會暫時或永久性地丟失。

這裡使用了“癱瘓”這個術語,以表示任何不能花費比特幣的尷尬情況。不幸的是,N-of-N的多重簽名方案無法解決癱瘓問題。事實上,它會使問題變得更糟,因為丟失任何一個金鑰都會是致命的。

出於這個原因,我們需要在滿足Richie及其合作伙伴目標的同時,也要避免掉癱瘓的情況,即需要讓所有人都同意花費這些比特幣,這似乎是不可能的!假設我們有一個N-of-N 的多重簽名方案,而要完成一筆交易,我們顯然需要讓所有合夥人同意簽署才可以做到。如果(N-1)位合夥人可以在某位合夥人的金鑰丟失的情況下,以某種方式獲得對比特幣的訪問許可權,他們可簡單地假裝其中一份金鑰已經丟失,並自行獲取資金。換句話說,我們實際上一開始實施的就是(N-1)of-N的多重簽名方案,這就產生了矛盾。

Richie的問題,似乎讓我們處在了癱瘓的狀態......

解決悖論

由於兩種強大技術的出現(區塊鏈和可信硬體),特別是英特爾SGX,事實證明我們實際上是可以解決這種悖論的。我們可以有效地在一般環境中做到這一點,據我們所知,這是有史以來第一次。為此,我們引入了一種稱為癱瘓證明(Paralysis Proof)系統的新技術

正如你會看到的,在以太坊平臺當中,我們可以相對容易地實施這種癱瘓證明系統,我們只需要用到一個智慧合約,而不需要英特爾SGX。我們在論文中提供了以太坊合約的例子。然而,比特幣中存在的指令碼約束,這使得它需要用到SGX裝置,並且還會引入一些技術挑戰。

簡單瞭解癱瘓證明系統

總體原理是相當簡單的。受信任的第三方,將所有的金鑰都儲存在託管處。如果一方或多方不能或不願簽署交易,則會導致上述的癱瘓情況,其他人則產生一個癱瘓證明,表明情況就是這樣的。鑑於此證明,第三方使用其持有的金鑰來授權交易。

但是,如果我們引入了一個可信的第三方,顯然,我們沒法實現Richie和他的朋友們提出的安全目標。因為有一方可以控制所有的私鑰!

而這就是SGX發揮作用的地方了。SGX應用,其行為基本類似於具有預定約束的可信第三方。例如,它可被程式設計,以便只有在提供有效證明時才能夠簽署交易。(從這個意義上講,SGX應用的行為與智慧合約非常相似。)感謝SGX,我們可以確保在可證實的癱瘓情況發生時,讓多數私鑰持有者能夠訪問到比特幣資產。

一些技術細節

當然,即使考慮到SGX的這種魔力,我們仍然需要確保癱瘓證明(Paralysis Proof)的生成是合法的。我們不希望Richie的合作伙伴能夠“指控”他,錯誤地聲稱他已經死亡,比如說對執行SGX應用的主機發起日食攻擊( eclipse attack)。令人高興的是,區塊鏈本身提供了一種強有力的方式來傳輸訊息,並讓某方知道傳輸者還活著。為了在比特幣網路上實施癱瘓證明系統,我們利用了這個事實以及一些技巧。為了簡單起見,我們將重點關注無法訪問的金鑰的問題,而暫時擱置其他形式的癱瘓情況。

一個癱瘓證明會被構建,證明某P方不及時響應(無法簽署交易)。該系統會發出一個挑戰(challenge),“被控”方必須對我們所謂的“生命訊號”作出迴應。如果在一段預定的時間內(例如24小時)沒有生命訊號響應這一挑戰,則這種缺席便構成了癱瘓證明。

而對於比特幣而言,P方的生命訊號,可以採用可忽略不計數量(例如0.00001 BTC)的比特幣UTXO形式,它可以是由P方發出(從而證明她還存在),或者透過pk_SGX發出(但需要等延遲過後才可以進行)。請注意,sk_SGX僅是被SGX應用所知的。

讓我們再拿三個合夥人作為例子。假設他們每個人都擁有一個金鑰對 (sk_i, pk_i)。首先,他們會託管自己的比特幣資金(假設有5000 BTC)到UXTO_0這個可花費的輸出,當三人都同意的情況,或者透過pk_SGX,就可以對其進行使用。現在,假設P_2和P_3決定指控P_1。SGX應用在收到兩人的請求之後,會準備以下兩筆交易,並將其傳送給P_2 和 P_3:

·  t_1(交易1)建立了0.00001 BTC 的生命訊號UTXO_1 ,對此pk_1可以立即使用它,或者在超時後(例如144個區塊,約24小時)可由pk_SGX使用;

·  t_2 (交易2)會花費UTXO_0以及生命訊號UTXO_1,然後將它們傳送到一個可由pk_2和pk_3控制的地址(或者,如果他們想要留在癱瘓證明系統當中,pk_SGX也是可選的)。

因此,指控P_1的合夥人應該向比特幣網路廣播t_1,等待t_1被新增到區塊鏈後,再等待接下來的144個區塊,然後將t_2廣播到比特幣網路。而在這期間,會出現兩種可能的結果:

· 在合法指控的情況下,P_1確實是無法使用t_1交易的,而一旦t_2交易被網路確認,則P_2和P_3將獲得比特幣的訪問權。這確保了BTC基金的可用性。

· 然而,在發生惡意指控的情況下,上述方案確保P_1在144個區塊時間內可提出上訴。為此,P_1可使用那個僅為她所知的金鑰,來花費UTXO_1。由於t_2將UTXO_0和UTXO_1都作為輸入,因此花費t_1,會使得t_2成為一筆無效交易。

安全論證

生命訊號的安全性,源於在t_1中使用了CheckSequenceVerify。詳細地講,只有當每個輸入的驗證部分(比特幣當中被稱為指令碼簽名-ScriptSig)都是正確的時候,t_2才會有效。SGX飛地裝置為花費託管基金而而生產的驗證部分會立即生效,但只有在t_1交易被納入比特幣區塊鏈之後(需等待144個區塊,由於CSV條件),花費t_1的驗證部分才會有效。因此,將超時引數設定為較大值有兩個目的:(1)給予P1足夠的響應時間,以及(2)確保攻擊者無法透過製造自己的鏈取代比特幣區塊鏈。

在以太坊平臺上的應用

以上提到的都是關於比特幣的例子,但癱瘓證明系統其實不僅僅可以應用於比特幣,對於像以太坊這樣的智慧合約平臺,其實現會更為簡單,我們可透過合約替換掉對可信SGX硬體的需求。

我們給出的參考實現程式碼只有117行,以下為其中的主要邏輯:

function spend(uint256 proposal_id) public {
  // Get rid of any paralyzed keyholders
  prune_paralyzed_keyholders();
  require(is_keyholder(msg.sender));
  require(proposal_id < proposals.length);
  // add sender's signature to approval
  proposal_sigs[proposal_id][msg.sender] = true;
  // if enough proposers approved, send money
  uint num_signatures = 0;
  for (uint256 i = 0; i < keyholders.length; i++) {   if (!paralyzed[keyholders[i]]) {   if (proposal_sigs[proposal_id][keyholders[i]]) {   num_signatures++;      }     }   }   if ((num_signatures) >= required_sigs) {
   if (!proposals[proposal_id].filled) {
   proposals[proposal_id].filled = true;
   proposals[proposal_id].to.transfer(proposals[proposal_id].amount);
     }
   }
 }
  function remove(address accused) public {
  // Get rid of any paralyzed keyholders (prevent paralyzed requester)
  prune_paralyzed_keyholders();
  // both requester and accused must be keyholders
  require(is_keyholder(msg.sender));
  require(is_keyholder(accused));
  // There shouldn't be any outstanding claims against accused
  require(!(paralysis_claims[accused].expiry > now));
  // Create and insert an Paralysis Claim
  paralysis_claims[accused] = ParalysisClaim(now+delta, false);
  NewAccusation(accused, now + delta); // Notify the accused
  }
  function respond() public {
  require(paralysis_claims[msg.sender].expiry > now);
  paralysis_claims[msg.sender].responded = true;
  }
完整的合約程式碼,讀者可訪問:https://github.com/pdaian/paralysis_proofs 檢視其它的應用
而除了密碼貨幣應用,癱瘓證明技術還可以應用於憑證解密。你可以使用癱瘓證明來建立一個用於釋放檔案的證明,允許一個人或一組人對其進行解密。以下是一些應用示例,這些策略可以透過區塊鏈(審查阻力通道)和SGX的組合來實現:· 每日支出限額:可確保在24小時內,從一個公共池中能夠花費的資金,不會超過一個預先商定的金額(比如說0.5 BTC,作者們在原論文中討論了一些實際限制)· 事件驅動的訪問控制:使用一個oracle,例如Town Crier系統(實際上是第一個面向公眾的SGX應用),這可以在現實世界的事件中對訪問控制策略進行條件化。例如,透過提供匯率資料反饋,每日支出限額可能以美元而非BTC計價。人們甚至可原則上使用自然語言處理響應現實世界的事件。例如,如果因為一份具有洩露資訊的檔案,其作者被美國聯邦政府起訴,那麼某個記者就可以對這份檔案進行解密。· 升級閾值要求:如果預先設定數量的參與者同意,就可以在訪問結構中新增和刪除參與者,即更改關於授權參與者數量的規則。例如,可以把k-of-N的多重簽名方案更改為(k+1)-of-(N+1)的簽名方案。在常規的秘密共享方案當中,這是不可能進行升級的,因為一組授權參與者總是可以重建他們持有的私鑰。但是,如果SGX應用控制瞭解密金鑰,它就可以監視區塊鏈,以確定參與者是否已投票進行升級,如果它們被記錄到了區塊鏈上,則投票不會受到抑制。存在的安全隱患以及未來的改進工作當然,在引入可信SGX硬體的同時,也會引入側通道攻擊((side channel attack)的風險,這也是這個方案主要會遇到的問題。而在未來的工作當中,我們將探索減輕這種攻擊的技術。例如,在一個允許N-of-N多籤方案可被降級為 (N − 1)-of-N多籤方案的系統,有可能讓一個SGX飛地應用儲存和有條件地釋放單個私鑰,而不是控制一個主私鑰。這將限制側通道攻擊帶來的危害。我們也可以在多個SGX飛地裝置儲存金鑰,這有助於減輕節點的失效風險,同時也有助於恢復節點故障,這是另一個需要去研究的工作。
附錄在論文當中,我們討論了很多有趣的擴充套件部分內容,以下是其中列出的兩點:利用契約(covenants)提議的癱瘓證明如上所述,由於比特幣存在指令碼約束,想要在該網路上應用癱瘓證明,就需要使用SGX裝置。實際上,我們還提出了一種不需要用到可信硬體,但“效率稍低”的方法,這就需要用到一種稱為covenants(契約)的提議比特幣功能。然而,使用這種方法的複雜性,明顯會高於SGX可信硬體方法(無論是概念還是鏈上覆雜性方面),因此我們並不推薦。另一種更好的方案在前面提到的例子當中,資金可以由pk_SGX單獨使用,但重要的是,這不是唯一的選擇。事實上,人們可以在安全性和癱瘓容忍度之間進行權衡,以最好地滿足他們的需求。
例如,如果三位合夥人只希望容忍最多一個缺失的私鑰,他們可以做的,是把資金轉移到一個3-of-4 的多籤地址當中,其中第四個參與者就是SGX飛地裝置。如果所有人都活著,那麼他們可以在不需要SGX的情況下使用比特幣資金。如果其中有一位合夥人出現了意外,他無法進行簽名,如果剩下的兩名合夥人能夠展示癱瘓證明,則SGX飛地裝置將釋放出它的私鑰。因此,即使攻擊者透過側通道攻擊攻破了SGX裝置持有的私鑰,他也無法花費這些比特幣資金,而唯一例外情況,就是兩位合夥人是和攻擊者串通好的。這也是我們打算進一步研究的一個有趣方向。

更多數字貨幣資訊:www.qukuaiwang.com.cn/news

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;