這段時間在各個學術論壇及會議上與很多專家交流研究零知識證明的心得。大家似乎都有個感覺是，零知識證明除了和區塊鏈相關的保密支付外很難找到其他靠譜的應用場景。我對零知識證明的應用場景做了些調研，這篇文章將探討零知識證明在傳統互聯網非支付領域的一個應用。具體來講，這篇文章將探討如何使用零知識證明構造隱私保護的reCAPTCHA。

背景知識：什么是reCAPTCHA

我們要談的這篇文章《zkSENSE： a privacy-preserving mechanism for bot detection in mobile devices》［PAZVNL］是由Brave Software公司研究員聯合馬德里卡洛斯三世大學和劍橋大學的研究人員合作的一個工作。這一章我們首先介紹下這項工作的動機：大家使用瀏覽器登錄網站時可能會經常碰到一個叫驗證碼的東西，比如向你展示一行歪歪扭扭的字，然后要求你輸入正確字句。

這種測試專業名稱叫Completely automated public Turing tests to tell computers and humans apart （CAPTCHA），翻譯成中文是用于區分計算機和人類的完全自動化的公開圖靈測試。這種測試在2000年左右互聯網初期時開始在網站建設中得到廣泛應用，主要目的在于使用這種測試檢測區分機器人和人類，進而阻止攻擊者通過使用機器人對網站發起拒絕服務攻擊或發送垃圾郵件惡意廣告等。

這篇文章重新設計CAPTCHA方案的動機略有不同，由于這個項目是由brave瀏覽器和basic attention token （BAT）項目的研究人員發起的，所以他們的應用場景和BAT的整個商業模式密切相關。BAT的基本宗旨是用戶應該為自己看廣告時付出的注意力得到補償，因此在用戶點擊觀看廣告時將會相應地收到一定量的BAT。這種商業模式有個專業名稱叫pay to surf，在1999年已經有人提出并實現過，當時一家叫AllAdvantage的公司通過這種付費給用戶看廣告的商業模式在不到一年時間內迅速吸引到了將近1300萬用戶和兩億美元的風投。后來網絡泡沫破滅，這家公司迅速倒閉。

這家公司最終失敗除了生不逢時，一個很重要的原因是攻擊者們使用機器人詐騙廣告點擊費過于猖獗導致公司最終入不敷出。事實上，我們知道這種類型的攻擊即使在今天依然非常常見的，網絡安全專業人士都知道攻擊者會通過購買低價手機來組成click farms以使用機器人軟件來騙取廣告費。所以這篇文章的背景就是，BAT意圖復興這種pay to surf商業模式，前提是他們必須避免重蹈AllAdvantage的覆轍，因而如何防止攻擊者使用機器人詐騙廣告費便成了重中之重了。

方案動機：為什么需要隱私保護的reCAPTCHA

那你可能會問既然已經有了CAPTCHA這個工具，Brave再另起爐灶重新搞一個基于零知識證明的機器人檢測方案豈不是多此一舉。這可能得從現有的CAPTCHA方案存在的問題說起。目前廣泛使用的CAPTCHA方案主要存在兩個問題：首先是其檢測機器人的效果還是有一定局限性的，尤其是目前基于深度學習的機器學習算法［GTFZFXCW18］已經能保證使用極少量的訓練樣本高效攻擊多個廣為使用的CAPTCHA方案；另一個問題則是在移動設備上CAPTCHA嚴重損害用戶體驗，這個相信大家在手機上碰到過驗證碼都有所體會。

針對這些問題，研究人員提出了一種新型的，對用戶透明的reCAPTCHA方案。其基本思想是通過收集移動設備上用戶個人數據來區分訪問者是機器還是人類。具體來講，其基本的思路是人在移動設備上輸入時需要按壓顯示屏，而觸屏時設備的慣性測量單元，即加速器和陀螺儀會記錄手指在屏幕上按壓移動時所產生的傳感器數據。相對而言，機器人則往往是通過軟件模擬來生成輸入的，由于沒有手指觸屏，所以傳感器不會收集到相關數據，因此這個傳感器輸出的差別可用于區分人類和機器人。

不過這種慣性測量單元數據從個人隱私角度看是非常敏感的，研究表明通過分析這些數據可以推導出設備上的按鍵（keystroke）信息，如用戶年齡，性別等，且這些數據可作為指紋信息來指認用戶。通過收集用戶按鍵（keystroke）信息甚至可以竊取用戶私鑰。BAT這個項目是以保護用戶隱私為立身之本的，如何能構造一個reCAPTCHA系統既能保證用戶隱私同時還能成功區分機器人和人類便成了這篇文章試圖解決的問題，這也是為何該系統最終使用了零知識證明的原因。

方案設計原則和安全模型

和傳統reCAPTCHA方案把移動端傳感器數據傳輸給互聯網公司控制的服務器，然后在服務器端上由公司分析用戶數據不同的是，這篇文章方案的基本原則是用戶數據不離開用戶移動設備，換句話說機器人檢測算法將在用戶設備上分析傳感器所收集數據，并將最終分析結果發送給服務器端，從而保護用戶隱私。這里順便提一下，BAT這種不讓用戶數據離開用戶設備且在用戶端處理隱私數據的原則非常有意思，應該能成為下一代隱私保護系統的一個通用設計原則。按照BAT項目創始人Brendan Eich的話說，這相當于從do no evil變成了can’t do evil。如果數據不離開用戶設備，那么對用戶數據擁有主權的顯然是用戶，而非互聯網壟斷公司們了。

從上面的背景介紹中我們可以看出，這篇文章顯然假設攻擊者控制了移動設備。既然機器人檢測算法在用戶設備端執行，如何保證算法所讀取傳感器數據沒被攻擊者篡改，如何保證即使在攻擊者有可能修改機器人檢測分析算法代碼的情況下所收集的分析結果依然正確便成了問題的關鍵了。

零知識證明正是用于保證分析算法結果的可靠性的。事實上，零知識證明如果只考慮其方案設計可靠性（soundness）的話，其實可以被看作計算證明（signatures of computation）方案。換句話說其所證明的是被承諾（committed）的輸入和輸出之間滿足預定的函數關系。如果輸入輸出之間不滿足這個預定的函數關系，攻擊者是無法生成可以通過驗證的證明的。如果把機器人檢測算法看作一個預定的函數的話，那么顯然零知識證明的這個soundness性質就可以保證一旦攻擊者修改機器人檢測算法代碼，它將無法生成合格的計算證明。而零知識證明的零知識性質則可以保證這個過程除了告訴驗證者檢測結果外不泄漏其他任何個人隱私信息，因此就能保證用戶隱私。

注意這個安全模型在實際中功能非常強大，這意味著系統在一個控制著大群移動設備（如click farms）的攻擊者發起攻擊時仍能有效檢測機器人且保證用戶隱私。這些可能的攻擊包括：攻擊用戶操作系統，修改用戶api，提供偽造傳感器輸出，重放合法用戶使用移動設備時所收集傳感器設備數據等。

方案簡介

這個方案的基本思想可以解釋成：用戶在移動設備的點擊事件將引發一個人類（humanness）認證過程，humanness證明模塊將讀取設備傳感器輸出。這個模塊將使用一個經過訓練的模型區分是人類還是機器執行了該點擊事件，并將檢測結果和對應零知識證明發給服務器驗證。零知識證明主要用于證明如下兩個計算步驟的正確性：

1. 機器人檢測程序輸入的數據確實是實時從傳感器采集的，且這些采樣算法運行正常。

2. 機器人檢測程序計算過程準確無誤。

具體技術細節上，該方案使用的是以太坊的一個通用的零知識證明代碼庫，具體使用的機器人識別算法則是基于支持向量機（support vector machines）的。由于現有的零知識證明只能支持整數輸入的，所以在技術細節上該方案做了些微調優化。另外由于這篇文章中使用的零知識證明算法初始化過程必須提前知道證明對應函數輸入向量大小的，他們預設向量維度大小上限為70。

展望

這篇文章實驗模擬比較了幾種手機上使用零知識證明的資源消耗，且對該方案在實際中應該如何使用提供了些建議。比如可以在移動應用代碼中引入一個SDK，然后周期性讓用戶手機做humanness證明。很明顯，用戶手機如果高頻地做這種零知識證明給手機帶來的額外計算負擔會很大，因此相應地耗電量可能也很大。這篇文章提出使用一個專用協處理器（co-processor）來專門做零知識證明運算。如果以BAT為代表的這種互聯網商業模式能得到廣泛推廣（目前brave瀏覽器已經有1000萬用戶了），那么這種專門用于優化零知識證明計算的硬件模塊恐怕勢在必行。

另外，這篇文章使用零知識證明方案由于需要trusted setup，且初始化參數和其使用的支持向量機算法相關，這在檢測機器人效果上有可能造成限制。相對而言，無需trusted setup的零知識證明方案，包括Suterusu項目目前研究實現的方案在支持通用的隱私保護機器學習方案具有一定的優勢，相信會在這種新互聯網經濟模式中大顯身手。
責任編輯；zl