CRSA：一種基于隱藏協助關系的數字資產恢復系統

在區塊鏈安全方面，隨著近年來數字貨幣的流行，越來越多的現實或虛擬資產選擇與區塊鏈相結合，通過分布式、公開透明的方式管理資產。用戶不再依賴于某個傳統中心化機構，而是通過獨有的非對稱公私鑰對以及對應地址來管理區塊鏈相關資產。這種新興資產管理方式的出現，也帶來了新的問題，由私鑰丟失造成的資產損失事件層出不窮，現有的區塊鏈資產以及私鑰管理方案沒有從根本上解決這個問題。為此，我們提出了一種基于隱藏協助關系的數字資產恢復系統CRSA，該方案能夠在協助者無感知的情況下將其綁定到需要保護的資產上，并且整個恢復過程不會暴露用戶和協助者的關聯性，更重要的是整個過程只需要協助者私鑰而不需要協助者保管額外的密鑰分片等信息。因此比傳統多重簽名、門限簽名等方式具有更高的安全性和更強的實用性。

該成果“CRSA: A Cryptocurrency Recovery Scheme Based on Hidden Assistance Relationships”發表于IEEE Transactions on Information Forensics and Security（TIFS 2021），是代煒琦老師帶領的區塊鏈團隊與美國德州大學圣安東尼奧分校的Kim-Kwang Raymond Choo教授的合作研究成果。TIFS信息安全領域的頂級國際期刊（CCF-A類），2020年JCR影響因子為7.178。

• 論文鏈接：
• https://ieeexplore.ieee.org/document/9511470

背景與動機

區塊鏈分布式自治，保障了用戶的權益，同時也讓私鑰保管個人化，個人保管私鑰易丟失，造成鏈上身份難修復：與傳統中心化系統身份認證方式不同，區塊鏈用戶自行保管私鑰對身份進行證明，對于一般用戶而言，安全管理私鑰非常困難，一旦私鑰丟失，用戶將無法自證身份，失去數字資產所有權，帶來經濟損失。2018年12月加拿大最大的數字貨幣交易平臺Quadriga CX創始人兼CEO Gerald Cotton突然去世，這些數字貨幣的密鑰只有Gerald Cotton掌握，帶走了平臺上價值高達1.9億加元（1.45億美元）的數字貨幣。

基于以上研究背景，我們提出了一種通過隱藏協助關系恢復數字資產的方案——CRSA方案，如圖1所示：當用戶私鑰丟失，無法控制資產時，用戶使用預先設置的隱藏協助關系等信息向區塊鏈中發起身份認證，并通過協助者輔助證明用戶身份的合法性，完成資產從舊地址到新地址的轉移。證明過程中，使用零知識證明保證資產恢復信息不會泄露給節點、協助者以及攻擊者，因此攻擊者無法得到關鍵信息：協助者列表信息、恢復證明信息、身份確認信息等。從根本上解決了私鑰丟失造成的鏈上資產損失問題。

圖1 系統流程概覽圖

威脅模型

此外，對整個系統流程建立了威脅模型并給出了對應的形式化證明。例如，攻擊者會試圖找到任何可能的漏洞來繞過CRSA方案設置的認證機制（威脅I）。假設攻擊者無法繞過驗證。此時，攻擊者需要獲取用戶的隱藏協助關系，并利用隱藏協助關系攻擊由用戶和助手組成的“多重簽名系統”，如勾結惡意協助者或攻擊協助者設備（威脅II），威脅模型如圖2所示。

圖2 威脅模型

因此對應CRSA的安全目標如下：

（1）認證不可繞過性：要求CRSA方案的所有資產回收驗證交易必須提交執行。（針對威脅I)）

（2）認證不可鍛造性：此屬性要求任何多項式計算能力敵手 都不能更改與用戶身份恢復相關的任何事務。（針對威脅II）

（3）協助聯系不可區分：除了公共信息外，此屬性要求賬本不向敵手 透露有關用戶協助關系的任何信息。（針對威脅II）

在CRSA 方案中，通過使用零知識證明隱藏了所有資產恢復協助關系，因此如何選擇助手、如何向助手證明、如何獲取特定助手的身份確認信息的過程，都不會向攻擊者透露任何有價值的信息。

CRSA方案設計

1. 在資產恢復預設階段，如圖3所示，為了避免資產丟失，Alice首先需要確定協助恢復資產的好友地址列表AddrList，并向區塊鏈網絡提交協助關系的相關“憑證”。當私鑰丟失了之后，用戶根據“憑證”找到AddrList中數量至少為threshhold的好友來協助他做資產恢復證明。證明時為了方便快速確認哪些好友地址存在于AddrList中，即證明用戶與好友之前存在社交關系，本文使用一個固定深度的默克爾樹AssistantMerkleTree來存儲AddrList，協助者地址的hash值填充到葉子節點中，空余的部分用零地址填充。同時為了避免攻擊者猜出用戶AssistantMerkleTree的結構，用戶需要選擇某一隨機排序算法來打亂葉子節點的順序，用戶需要保證在恢復秘鑰時也能夠得到對應的葉子節點順序。最后，Alice發送新增交易Commit Tx將（C_id, r₁）傳入區塊鏈網絡，當區塊鏈中節點確認交易的有效性之后，生成交易哈希CommitHash，指向Commit Tx。同時，在區塊鏈中設一個名為UsedCommits的哈希表，保存了所有被用過的Commit Tx的哈希，也就是說，這些Commit Tx所指向的用戶地址都已經發起過資產恢復請求并成功執行了。

圖3 資產恢復預設步驟關鍵流程示意圖

2. 在資產恢復請求階段，如圖4所示，當Alice不小心丟失私鑰之后，為了恢復資產，她需要在區塊鏈網絡中向協助者請求協助，證明其對資產的所有權，將資產轉移到其新地址。為此，她需要向協助者證明自己的身份，由于在區塊鏈網絡中，鏈外的信道處于一種不可信的狀態，很容易遭受黑客攻擊，使得協助者難以確認Alice的恢復請求的合法性，因此鏈外信道僅用于通知協助者。然后Alice在鏈上提交相關證明，使得好友能夠從鏈上確認Alice知道資產恢復信息。

圖4 資產恢復驗證階段關鍵步驟示意圖

首先，Alice需要向協助者證明他知道addr_A在資產預設階段選擇的好友列表AddrList、協助者門限threshhold，能夠以此構造出預先設置的C_id。但是如果Alice直接向區塊鏈節點提供AddrList以及threshhold，黑客和惡意節點就有可能進行中間人劫持，冒充Alice發起資產恢復請求來盜取資產。為了保護資產恢復信息的機密性，在這里使用zk-snark，生成零知識證明結果π_req，即在不泄露具體信息的情況下證明Alice知道C_id的構造元素。同時為了避免黑客竊取π_req為其他地址做證明，π_req還需要證明發起資產恢復的新地址addr_new的合法性。也就是說，使用addr_new的用戶也得知道資產恢復信息(AddrList、threshhold )。為了證明這點，用戶A需要將（AddrList、threshhold、addr_new）使用COMM獲取新的承諾值C_id'，addr_new作為x的具體值在COMM中使用。

接下來，Alice通過鏈下可信信道與她的協助者聯系（比如一些應用、電子郵件、電話、特定服務商驗證等方式）。這些協助者確認Alice是否真的丟失了相關的私鑰，相關的資產恢復請求是否是合法的。當所需部分都生成好之后，Alice從新地址通過新增交易PreTransfer Tx將（CommitHash, addr_new, C_id', π_req）都發送給節點，節點需要CommitHash確認是否指向了一個合法的Commit Tx，即CommitHash不在UsedCommits中，對應資產在之前沒有發起過資產恢復服務請求。驗證如果都能通過，生成一個空列表VList用于記載已經完成協助證明的協助者序號，該序號指的是協助者地址在協助者關系樹AssistantMerkleTree中的序號，并得到當前交易的哈希PreTransferHash。

3. 在資產協助恢復階段，當協助者收到用戶通知之后，首先他（或她）需要從鏈上獲取零知識證明π_req來驗證請求的合法性，再通過其他鏈下聯系渠道和用戶確認是否是其本人發起的資產恢復請求。如果以上驗證都通過了，說明用戶舊地址的私鑰確實丟了。接下來本文以Alice的第i位協助者Bob來進行說明。Bob在得到Alice聯系（電話、短信、Email等）之后，需要對這個交易進行如下驗證：i）從對應CommitHash指向的Commit Tx中取出C_id和r₁，以(addr_new，C_id , C_id'，r₁)和π_req作為輸入，檢查是否能通過零知識驗證。ii）根據Alice的鏈下聯系，判斷是否是Alice本人發起的這筆交易。

在確認Alice丟失舊地址私鑰的事實之后，Bob能夠大致判定，addr_new就是Alice的新地址。接下來，Bob需要向區塊鏈網絡為Alice提供相關的身份證明材料，證明Alice在新地址addr_new上擁有對舊地址addr_A的資產所有權，同時不能夠暴露其與Alice之間的社交關系。若驗證通過，Bob可以基本確定Alice確實丟失了私鑰，addr_new就是原資產擁有者的新地址，接下來需要為Alice做出相關身份背書，即對之前Alice提交的交易PreTransfer Tx生成驗證結果。最簡單的方法是直接將PreTransferHash通過Bob的私鑰簽名，以交易的方式發送到鏈上，但是這樣一來，Bob與Alice之間在鏈上的協助關系就會直接暴露，使得攻擊者可能會就協助關系這一點進行惡意攻擊，帶來了安全風險。為了避免社交關系泄露，選擇發送PreTransferHash的一個承諾值。選取隨機參數r_3i通過COMM為PreTransferHash做混淆，生成C_reqi, 同時為了能夠讓Alice在之后使用這個承諾值，“證明”其與Bob的好友關系，使用Alice的新公鑰PK_new將r_3i加密得到verificationReceipt_i。通過verification Tx將C_reqi和verificationReceipt_i發送到區塊鏈網絡。

圖5 資產協助恢復關鍵步驟示意圖

并且由于好友證明的混淆性，節點可以將在當前區塊生成期間收集到的所有證明添加到一個VerificationList中，證明可能是針對同時進行恢復的多筆資產的，并且為了能夠方便在之后擴展新的好友證明，避免因列表線性增長所帶來的相關算法復雜度開銷，將VerificationList中的元素通過抗碰撞函數CRH構造默克爾樹來收集好友證明，該默克爾樹稱為VerificationMerkleTree。同時，為了避免攻擊者冒充好友為某個非法PreTransfer Tx做確認證明，區塊鏈中的節點為此加入公開可驗證的好友地址addr_i，選取隨機數r_2i，通過COMM對addr_i、C_reqi生成C_veri，以此確認相關承諾值與好友地址之間的聯系。并且，將C_veri作為葉子節點添加到VerificationMerkleTree中。整個過程如圖5所示，Bob將（C_reqi，addr_i，C_veri，r_3i，verificationReceipt_i）通過交易verification Tx發送給節點交易上鏈。

綜上所述，攻擊者可以獲取Bob的地址和生成的結果C_reqi、C_veri和verificationReceipt_i，但是難以發現Alice與Bob之間在地址上的聯系，無從發起攻擊。

4. 在資產恢復驗證階段，協助者為Alice構建資產損失背書后，愛麗絲需要證明addr_new和助手的地址addr_i（0 ≤ i ≤ n）之間的協助關系。在足夠多的協助者證明了區塊鏈網絡中的隱藏協助關系之后，就可以確定愛麗絲是原始資產的所有者，該資產屬于addr_A。為了避免攻擊者從中獲取用戶Alice的隱藏協助關系，用戶Alice需要使用零知識證明來證明兩點：1）有某個協助者為Alice做了身份驗證，C_veri在VerificationMerkleTree的某個葉子節點上, Alice證明其知道協助者提交的證明的構造結構，同時不指出哪一個C_veri與Alice相關；2）已經有超過預設threshhold數量的協助者為Alice做出了驗證，證明了用戶對原有資產的所有權。為了方便描述，將整個證明分為兩個部分來進行設計，但是在實現階段可以將兩部分的內容整合在一起進行證明。

(1) 階段一

首先，Alice需要證明第i（0 ≤ i ≤ n）個協助者已經做出了協助證明；也就是說，協助者為Alice做的“背書證明”目前是VerificationMerkleTree的葉子節點，并且協助者的地址addr_i 在Alice之前那預生成ObfuscatedAddrList的中。Alice需要從區塊鏈中獲取當前VerificationMerkleTree的默克爾根verification _root ，以及與C _veri 對應的路徑證明verification_i_merkle_proof證明。同樣的原因，獲取addr_i 在VerificationMerkleTree的默克爾路徑證明verification_i_merkle_proof。然后，從對應的Commit Tx中得到C_id ，r ₁ 。最后，通過SK _new 從驗證收據verificationReceipt _i 中獲取r _3i 。然后Alice針對NP問題NP _Announce 零知識證明。

為了方便接下來的討論，簡化了上述NP問題，將零知識證明結果生成標記為FPG(input)=(π_FVi，k_addri)，其中輸入表示零知識證明過程中使用的公共輸入和秘密輸入，π_FVi是零知識證明，而k_addri是ObfuscatedAddrList中addr_i的序列號。在圖6中，用FPG(*)來表示相關操作。

圖6 資產恢復驗證階段一關鍵步驟示意圖

生成π_FVi之后，Alice將（PreTransferHash，verification_root，π_FVi，k_addri）通過交易Recovery Tx提交給節點。區塊鏈節點通過驗證零知識證明結果和公共參數的有效性來判斷該交易的有效性。如果驗證通過且k_addri不在VList中，將其加入VList。本步驟流程如圖6所示。

（2）階段二

Alice需要證明協助她證明新地址合法性的協助者的數量大于threshhold。因此，Alice根據NP語句transfer生成零知識證明。在這時，零知識證明結果π_transfer獲取之后，Alice通過向節點提交特殊交易Prove Tx將（PreTransferHash，CommitHash，π_transfer）添加到鏈上。節點通過對應的交易哈希獲取對應的公共輸入。當驗證完零知識證明的正確性之后，節點這個Prove交易打包進區塊，并發布到區塊鏈網絡。本步驟流程如圖7所示。

圖7 資產恢復驗證階段二關鍵步驟示意圖

5. 在資產恢復公示階段，節點驗證參數的有效性并通過零知識驗證后，會有一個常數K塊的發布周期。這一公示期是為了避免黑客通過本服務在用戶Alice沒有丟失私鑰的情況下，盜取用戶資產，一旦用戶Alice發現，可以立刻發布撤銷交易，挽回資產損失。若沒有其他用戶提出撤銷交易，那么節點將自動發起資產轉移操作，將原有資產轉移到新提交的地址中。

鏈上資產轉移交易的監控可以通過簡單的腳本文件或特定服務提供商實現。這樣的監控可以讓用戶更有效地發現區塊鏈上的任何異常資產恢復行為嘗試。一旦公布期到期，節點將自動發起一個特殊的資產轉移交易，將原始資產轉移到新提交的地址addr_new。

這個特殊轉移交易由挖礦節點簽名并發起，這個交易表示經過一定數量的協助者的“背書”和K個區塊的公示，地址addr_A的私鑰丟失，并且addr_new對于addr_A擁有對應的合法資產所有權。

CRSA系統構造與實現

CRSA基于以太坊實現了相關原型系統。為了在以太坊上使用zk-SNARKs，有必要擴展其契約解釋引擎EVM，使其能夠支持zk-SNARKs的驗證。同時，還需要擴展通過web3接口連接到節點的應用程序，使其生成零知識證明并發送到節點。為了在CRSA方案的主要流程步驟完成后能夠在不使用用戶私鑰的情況下傳輸資產，在底層EVM中添加了一個相關的調用方法。它只能由相應的挖掘節點根據之前生成的Prove Tx調用。整個程序的整體結構如圖8所示。

圖8 整體實現架構預覽

實驗結果如圖9所示，除了證明秘鑰根據電路大小有關，隨著電路邏輯的負載而擴張以外，其大小基本都在20M左右，驗證秘鑰的大小大致不到2K，零知識證明結果的大小也比較固定，大致只有298B大小，多線程情況下驗證時間大致在30ms左右，證明相關的時間在開多線程的情況下可以小于2s。由此說明，相關零知識證明不管是證明時間還是驗證時間，都在可以接受的范圍。通過交易并發性測試等項目證明了對原系統的性能影響不大，交易費用也在可控范圍內。

圖9 零知識證明相關結果展示