上海交大劉志強：安全與隱私保護依然是區塊鏈亟需解決的問題
2018年11月17日上午，“2018比原鏈全球開發者大會”正式在杭州國際博覽中心（G20會館）開幕，這是杭州第一次由開源組織舉辦的技術型峰會，也是杭州被譽為區塊鏈之城以來規模最大的一場區塊鏈開發者大賽，100+開發團隊歷經4個月激烈廝殺，16支團隊將在本次大會上展開最終角逐。
上海交通大學密碼與電腦保安實驗室區塊鏈技術研發團隊負責人博士生導師劉志強發表主題為《隱私保護與數字錢包安全》的演講。
劉志強對當前區塊鏈系統中的主流隱私保護技術及特性做了介紹並指出其中面臨的隱私不足問題，如 基於混幣的隱私保護技術 如果基於第三方會有隱私洩露，如果基於相對去中介的，可能在混幣層面內部有隱私洩露。 基於環簽名的隱私保護 存在交易匿名性存在風險， 基於零知識證明的隱私保護 技術中的ZK-STARK由於整個系統需要可信啟動，與區塊鏈的最初設計理念有些不符。
數字錢包私鑰安全存在著黑盒模型、灰盒模型和白盒模型，三者存在的安全風險依次增加。對於安全威脅程度最高的白盒模型劉志強提出了SM2簽名演算法的解決方案，保證在白盒攻擊模型下簽名不可偽造性以及在白盒攻擊模型下原始簽名私鑰不可計算性。當然，實現了白盒方案的數字錢包還可能面臨的安全威脅：Code lifting，這時候就要採取程式碼混淆技術。
以下是劉志強演講內容，巴位元整理：
首先非常感謝主辦方能夠邀請我來和大家探討和分享區塊鏈隱私保護與安全問題。區塊鏈希望在一個相對較弱的信任環境下構建一個非常強的信任機制，安全和隱私問題一定是區塊鏈裡非常重要，非常關鍵的問題，也是大家非常關心的問題。
區塊鏈安全問題涉及到非常多的層面，我們知道一個系統的安全涉及到非常多的層面。比如說從共識機制的安全性，智慧合約安全性，數字錢包、私鑰的管理。如果涉及到區塊鏈的監管，在監管和隱私保護之間怎麼樣達成一個平衡等等。因為我們在區塊鏈裡應用了一些密碼技術，密碼演算法本身理論上是安全的，但如果非密碼專業的人去實現密碼演算法的時候，可能會存在相應的漏洞，後面會有一些例子給大家介紹一下。
我們現在也有一些擴充套件機制是通過鏈下的方式，怎麼樣保證離鏈交易安全性等等。今天我們不會就所有問題展開，我們會比較關注於某些方面探討隱私保護特性，以及對數字賬戶安全性做一個非常初步的探討。
區塊鏈系統裡的隱私保護物件是什麼，我們假設以Blockchain為例，需要對雙方身份隱私進行保護，對交易金額希望進行一定的保護，並且對交易不可追蹤性。如果交易路線圖能夠被追蹤出來，事實上隱私洩露也是非常嚴重的。
區塊鏈系統中的隱私保護—技術
區塊鏈系統中的隱私保護主流技術有混幣、環簽名、零知識證明、MPC、同態加密。
基於混幣的隱私保護技術有些代表性工作，這裡面一開始都會基於可信中介，混幣有一箇中心繫統的。後面發展到怎麼樣把可信的中介去掉，因為引入可信中介與區塊鏈本身設計思想是會有些相背的，那它就會考慮怎麼樣把中介可信性去掉，就引入了去可信中介的機制TumbleBit。還有去中介的混幣，目前比較有代表性的CoinShuffle，這種技術在混幣裡還是非常有效的。當然它的特性就是把交易的輸入輸出進行混合，打亂輸入輸出之間的關聯性，所以它是比較直觀，但不隱藏金額，而且混幣技術一般來說要求固定切分的金額。
基於環簽名的隱私保護，這裡比較有代表性的就是門羅幣。它的技術特性會使用一次性地址，每次A使用者向B使用者傳送一筆交易時，會根據B使用者公開的資訊，公鑰，產生一次性地址，會通過承諾以及環簽名，把傳送者和接收者地址、交易金額都能保護得非常好，都能把它的隱私進行一定保護。
基於零知識證明的隱私保護技術，比較有代表性的Zerocoin，它是基於零知識證明技術，可以完全隱藏輸入輸出地址和交易金額。這是目前相對比較強大的，當然它的效能效率目前可以接受，但還是在這一塊上有更進一步的研究。
區塊鏈系統中的隱私保護—現狀分析
這些隱私保護技術還有哪些問題呢？基於混幣的隱私保護技術如果基於第三方會有隱私洩露。如果基於相對去中介的，可能在混幣層面內部有隱私洩露，同時它的通訊複雜度相對偏高，所以只支援少量成員的混幣技術。
基於環簽名的隱私保護，如果大家對門羅幣進行可追蹤分析的話，會發現對目前門羅幣交易資料，我們事實上已經有它的匿名性分析結果。
基於零知識證明的隱私保護技術，因為ZK-SNARK本身有一個缺陷，系統需要可信啟動，啟動過程中產生PK、VK引數時，需要一個可信的實體，相對來說你要相信它，這與區塊鏈最初設計理念有些不符。
今年也出現了關於Zerocash隱私洩露分析，是由於使用者習慣導致的隱私洩露。後來又提出ZK-STARK，改進了它的可信啟動缺陷，並且可以支援抗量子計算。當然它也有它的問題，大家如果關注隱私這一塊，應該會比較關注，結合環簽名技術裡進一步改進它的範圍證明，用於保護交易金額隱私高效技術。
門羅幣的隱私保護特性分析
我們再看一下門羅幣隱私保護特性分析，不可連結性、不可追蹤性、交易金額隱藏。實踐中我們看一下，它的不可追蹤性受到一定挑戰。這裡定義了有效的匿名集大小，通過鏈式反應，我們在做門羅幣隱私保護時，交易時對每筆交易輸入需要引入一些混合資訊構成一個集合。在這個集合裡，你無法判斷輸入到底來自於集合鏈哪一筆。我們通過對它的資料分析，可以構建輸入與輸入之間鏈式反應，使得它的匿名集變小，可追蹤性會受很大的影響。
還有在門羅幣裡一個非常有意思的攻擊——時間攻擊，用來混合輸入的集合，一般來說最新的輸入就是真實的輸入。有人對門羅幣交易資料進行了分析，發現這樣的概率是非常大的。那就意味著你在一個集合匿名集裡引入10個輸入，雖然別人不知道是10個輸入裡哪個，實際上我只要進行簡單的時間分析，哪筆交易輸入是相對比較近期的，那它就有非常大的概率是真實的輸入，所以它的可追蹤性就受到很大挑戰。
ZCash的隱私保護特性分析
ZCash的零知識證明技術理論上是非常強的，但是我們會通過ZCash本身交易資料，交易種類的分類發現，它會存在一些隱私洩露情況。通過這張圖可以看到，如果把交易分成4類，比如透明交易，事實上沒有進行任何保護，沒有真正做隱私交易，t-to-t。還有t-to-z，z-to-z。這裡可以看一下各類交易情況，透明的交易完全沒有用到隱私保護的，竟然佔了73.5%，transaction，生產交易也是沒有隱私保護的，這裡佔了11.5%。
通過這個分析我們發現，還有一些用了這個技術的，比如挖礦出來之後有一個激勵，酬金會先放到隱私庫裡，進去一次馬上出來。這樣子的話，事實上對隱私洩露是非常有影響的。
雖然ZCash本身隱私保護機制是非常強的，但因為使用不當，裡面隱私洩露的情況是比較嚴重的。
密碼演算法的實現安全
我們再看看密碼演算法的實現安全，區塊鏈裡面涉及到的密碼演算法，包括金鑰生成演算法、Hash演算法、數字簽名演算法、加密演算法、承諾演算法、零知識證明演算法等。演算法安全性是理論上可證明安全性，還有在軟硬體實現中的安全性。
密碼演算法實現中的安全問題包括：
隨機數重用問題，很多時候在實現時尾隨數生成，這裡做得不夠規範，沒有遵循設計規範，使得隨機數有問題，這會使得私鑰洩露。
演算法誤用問題，現實的安全目標與理論的安全模型是不是一致，演算法的填充是不是符合規範。比如常用的數字簽名ECDSA，若（r，s）是對訊息m的有效簽名，則（r，-s）也是對同一訊息m的有效簽名，這個問題曾經導致某個交易所的重大問題。
側通道攻擊問題，問題的關鍵在於資訊洩露途徑的多樣性。CCS 2017上提出了對當時基於格的最快速的數字簽名BLISS的側通道攻擊。
數字錢包私鑰安全
數字錢包的賬戶安全，面臨三種攻擊模型：
黑盒模型，敵手能力非常有限，獲取資源非常有限，所以它是把整個密碼演算法實現當成黑盒，只能去竊聽通訊通道。通過理論的分析，獲得資訊非常有效。
灰盒模型，攻擊者資源得到一定擴大，系統在執行過程中，它的執行時間、功耗、電磁輻射，甚至可以通過注入錯誤來獲取一些旁路資訊，這些旁路資訊對於匿名資訊分析和提取非常有幫助。
白盒模型，這時候攻擊者能力得到非常大提升，可以完全訪問密碼演算法執行，可以觀測密碼演算法動態資訊，並且對記憶體進行讀取分析，甚至可以插入一些錯誤改變程式運營結果。
三種攻擊模型下安全強度，白盒攻擊威脅程度非常大。為什麼我們要考慮白盒環境下安全機制呢，因為在很多不信任終端環境下，特別是軟體環境下，這時候敵手是可以具有很強大的攻擊能力。舉個例子，AES，這是一個非常經典的，應該說也是應用非常廣泛的密碼演算法。在黑盒環境下，目前從97年提出來到現在20多年了，從理論上分析仍然是安全的。
現在對於（8/10）的AES，攻擊的輪數只能到第8輪，它的安全複雜度只能降到2的100次方而已，黑盒環境下比較安全的。灰盒環境下是不加防護，完全不安全。如果是在白盒環境下，它的安全性沒有任何安全性了。
數字錢包SM2的演算法，國密演算法。國家對網路空間安全非常重視，密碼技術又是網路空間安全裡支撐技術，所以現在國家《密碼法》草案已經出來了。以後隨著《密碼法》推行，國密演算法一定會受到越來越多的重視。以後我們肯定會考慮區塊鏈裡簽名演算法切換，這是非常有可能的過程。如果是SM2簽名演算法的話，我們怎麼樣保護這個簽名演算法本身在白盒攻擊下安全性，如下圖所示。
我們希望達到的安全性是在白盒攻擊模型下簽名不可偽造。哪怕敵手有非常強的能力，仍然不能去偽造簽名，或者是仍然不能把原始私鑰恢復出來。實際上是通過無金鑰的方式，把金鑰藏在表格中，然後基於困難問題可以證明安全性。
隨機數可能是很多人會忽略的，認為只要保護好私鑰。事實上在這個簽名過程中，如果隨機數洩露，那麼就可以通過計算過程把私鑰推出來。
實現了白盒方案之後的數字錢包仍然還存在可能的威脅，那就是會被Code lifting，即軟體程式碼可能會被整體複製，在其他裝置和環境下執行，進行Code lifting攻擊。這時候就會使用到程式碼混淆技術，包括表層混淆、控制流混淆、深度混淆。