這段時間在各個學(xué)術(shù)論壇及會議上與很多專家交流研究零知識證明的心得。大家似乎都有個感覺是，零知識證明除了和區(qū)塊鏈相關(guān)的保密支付外很難找到其他靠譜的應(yīng)用場景。我對零知識證明的應(yīng)用場景做了些調(diào)研，這篇文章將探討零知識證明在傳統(tǒng)互聯(lián)網(wǎng)非支付領(lǐng)域的一個應(yīng)用。具體來講，這篇文章將探討如何使用零知識證明構(gòu)造隱私保護的reCAPTCHA。

背景知識：什么是reCAPTCHA

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

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

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

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

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

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

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

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

方案設(shè)計原則和安全模型

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

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

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

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

方案簡介

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

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

2. 機器人檢測程序計算過程準(zhǔn)確無誤。

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

展望

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

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