作者：李昊軒
來源：微衆銀行區塊鏈
牢不可破的密碼學算法也怕物理攻擊？物理信號泄露爲何會威脅到隱私保護的效果？ 隱私保護方案對部署環境有何講究？不可信執行環境下如何設計隱私保護方案？
這裏，我們將繼續安全模型的分析，由隱私保護技術方案中理論層面的能力邊界，擴展到實際開發部署時工程層面的能力邊界，梳理工程實現中相關安全假設，以及適用的業務場景。
在上一論中，我們介紹了多種不同的安全模型，來衡量基於密碼學隱私保護技術方案的理論強度。然而，一個隱私保護技術方案如果只考慮理論層面的安全，而忽視工程層面的安全，其有效性是值得質疑的。
早在1985年，Wim van Eck在論文中提出，攻擊者可以通過軟件運行時產生的電磁輻射信號，結合統計學分析方法，破譯出電子設備正在處理的機密信息內容。這就是一種典型的側信道攻擊，是密碼學工程領域不能忽視的風險。
與密碼學理論領域的安全模型類似，對於密碼學工程領域的安全風險，我們也可以根據其安全假設來定義對應的安全模型。最常見的三類安全模型如下：
- 黑盒安全模型
- 灰盒安全模型
- 白盒安全模型
以上三類安全模型中，密碼學系統對部署環境的信任要求逐步降低。本論，我們將繼續敘說小華的故事，以小華向好友美麗發送私密信息時的加密過程爲例，一一闡述這三類安全模型對於企業隱私保護技術選型的影響和啓示。
1.黑盒安全模型
科班出身的小華，對於自己的技術能力相當自信，打算以加密信息的方式，給他的好友美麗一個驚喜……
小華選用了業界標準AES加密方案，將他的私密信息，用特殊的方式傳達給美麗。小華使用了公用機房中的電腦，開發並運行了對應的技術方案，產生了密文信息。
不巧的是，公用機房中的電腦被攻擊者植入了木馬，木馬通過讀取代碼執行時的電量消耗和其他中間狀態信息，破譯了小華私密信息的明文。
實際上，除了基於密碼學技術構建的軟件技術方案，就連基於可信硬件模塊構建的硬件技術方案，也會不同程度受到以上這類隱私風險的影響。但是，我們依舊認爲這些方案在常見業務環境中是安全可用的，究竟是何緣故？
這就引入了黑盒安全模型的定義，假定技術方案的執行過程對於外界是一個完全封閉的黑盒。
如果我們把整體的隱私技術保護方案抽象成關於隱私數據x的一個函數y = f(x)，對於攻擊者而言，只能獲得y，無法獲得f(x)在運算過程中產生的任何中間狀態信息。
中間狀態信息包括直接敏感信息和間接敏感信息：
- 直接敏感信息：計算過程中的內部變量值、代碼執行軌跡等
- 間接敏感信息：執行時間、設備能耗、內存用量、電磁輻射等
絕大多數密碼學算法實現，如AES加密算法的標準實現等，都是基於黑盒安全模型的。
這意味着，即便對應的密碼學算法和協議設計達到了理論能力的上限，信息論安全在黑盒安全模型要求的假設被打破的前提下，依舊可能泄露隱私數據。
反過來講，對於受控的業務環境，可以保證沒有攻擊者能夠進入機房，或者難以通過其他方式遠程獲得這些中間狀態信息，而且對應軟硬件模塊的配置和使用都正確，那麼對應的技術方案還是安全的。
考慮到隱私和效率的取捨，黑盒安全模型下的技術方案，工程實現相對複雜度低，能夠提供高效的系統實現，可用於中間狀態信息泄露風險低、可控部署環境中的業務場景。
2.灰盒安全模型
小華吸取了上次的教訓，優化了加密算法的實現，屏蔽了執行時間、設備能耗等常用中間狀態信息泄露。新的方案似乎生效了，攻擊者之前部署的木馬無法獲得有效信息來破譯小華的私密信息。
小華的優化一定程度上降低了隱私保護技術方案對於部署環境的信任要求，相比之前的黑盒安全模型，這裏的安全模型爲灰盒安全模型, 允許一定程度的中間狀態信息泄露。
灰盒安全模型，要求技術方案能夠防範由於常用中間狀態信息而導致的隱私信息泄露。常用中間狀態信息，一般指技術方案執行過程中，容易從外部觀察到的各種物理信號，如執行時間、設備能耗、電磁輻射、聲波信號等。這一類的攻擊通常被稱爲側信道攻擊、旁路攻擊，或統稱爲灰盒攻擊。
爲了應對這些灰盒攻擊，需要在原先黑盒安全工程實現的基礎上改寫算法，使得在不同輸入下，所需防範的物理信號表現相同。以最常見的執行時間分析攻擊爲例，灰盒安全模型下，對於所有的輸入，技術方案的執行時間總是保持均等，以此避免由於執行時間存在差異，而泄露關於隱私數據的信息。
然而，這一類灰盒安全技術方案在系統效率上的副作用也很明顯。即便某些執行路徑可以更高效地執行，也需要特意降低其效率，使之與業務邏輯中效率最差的一條執行路徑相匹配，以此確保執行過程使用的時間、消耗的能量等外部可觀測物理信號，在任意輸入下都不表現出顯著差異。
由此可見，灰盒安全技術方案的執行效率總是由業務邏輯中效率最差的一條執行路徑來決定，這對系統效率的優化帶來了一定的挑戰。
相比黑盒安全模型，灰盒安全模型對於部署環境的信任要求更接近現實情況，一定程度上考慮了內部人員風險等原本只能通過治理手段才能防範的隱私風險，具備更實用的抗攻擊能力。
灰盒安全模型下，技術方案的應用主要用於防範內部人員風險，或者在不完全可信的外包環境中部署運行業務。
3.白盒安全模型
好景不長，攻擊者發現之前部署的木馬失效之後，升級了木馬程序，小華的灰盒安全方案並不完美，攻擊者獲得了技術方案執行過程中的內部變量值，小華的私密信息再次遭到破譯。
灰盒安全模型雖然對中間狀態信息做了一定的保護，但無法保證所有的中間狀態信息都能得到有效保護。如果能夠實現這一點，就達到了工程層面中最強的白盒安全。
回到定義黑盒安全模型的公式，隱私技術保護方案可以抽象爲關於隱私數據x的一個函數y = f(x)。在白盒安全模型下，除了x之外，攻擊者可以獲得y和f(x)在運算過程中產生的任何中間狀態信息。
白盒安全模型假定執行環境完全對攻擊者透明，聽起來效果很玄幻。但密鑰如何保護？明文輸入不是直接就被看到了嗎？面對如此強大的攻擊者，如何才能保護隱私數據的安全呢？
效果確實很玄幻，目前現有研究對白盒安全模型的定義做了一定的弱化，通常會把保護目標限定爲即便攻擊者控制了整個執行環境，也無法輕易通過內存讀取等方式提取出密鑰。
爲了實現白盒安全，需要在灰盒安全的基礎上進一步打亂混淆密鑰的存儲方式並改寫算法，讓正確的密鑰能夠在執行過程中被間接使用。這一工程安全要求進一步提升工程實現的複雜度，例如，AES加密算法的白盒安全實現要比黑盒安全實現慢10倍以上。
儘管白盒安全模型下的大部分技術方案目前尚不成熟，在方案可用的前提下，對於需要在不可控的公開環境中部署的業務，如公共物聯網應用，非常有必要考慮使用白盒安全技術方案，用以保護終端設備中的密鑰、控制隱私數據的泄露風險。
正是：密碼巧妙理論無破綻，工程精細實現需謹慎！
工程安全和理論安全是相互獨立的兩個維度，理論安全並不等於工程安全。再強的理論安全方案設計，也會因爲不當的工程實現而導致前功盡棄。
瞭解密碼學工程領域的安全風險，對於實際應用落地和安全運行至關重要。企業在對基於密碼學技術的隱私保護技術方案選型時，需要理論聯繫工程，根據自身的業務場景和部署環境的特徵，選擇合適的安全模型，確保隱私保護技術方案的最終有效性。
在這兩論中，我們對密碼學技術選型中的理論能力邊界和工程能力邊界進行了分析。除了算法理論和工程實現中的諸多安全假設，新興的量子計算和量子通信也對隱私保護技術方案的有效性帶來了挑戰，具體分析，敬請關注下文分解。
《隱私保護週三見》
“科技聚焦人性，隱私迴歸屬主”，這是微衆銀行區塊鏈團隊推出《隱私保護週三見》深度欄目的願景與初衷。每週三晚8點，專家團隊將透過欄目和各位一起探尋隱私保護的發展之道。
欄目內容含括以下五大模塊：關鍵概念、法律法規、理論基礎、技術剖析和案例分享，如您有好的建議或者想學習的內容，歡迎隨時提出。
欄目支持單位：零壹財經、陀螺財經、巴比特、火訊財經、火星財經、價值在線