不巧的是，公用機房中的電腦被攻擊者植入了木馬，木馬透過讀取程式碼執行時的電量消耗和其他中間狀態資訊，破譯了小華私密資訊的明文。
實際上，除了基於密碼學技術構建的軟體技術方案，就連基於可信硬體模組構建的硬體技術方案，也會不同程度受到以上這類隱私風險的影響。但是，我們依舊認為這些方案在常見業務環境中是安全可用的，究竟是何緣故？
這就引入了黑盒安全模型的定義，假定技術方案的執行過程對於外界是一個完全封閉的黑盒。
如果我們把整體的隱私技術保護方案抽象成關於隱私資料x的一個函式y = f(x)，對於攻擊者而言，只能獲得y，無法獲得f(x)在運算過程中產生的任何中間狀態資訊。
中間狀態資訊包括直接敏感資訊和間接敏感資訊：
· 直接敏感資訊：計算過程中的內部變數值、程式碼執行軌跡等
· 間接敏感資訊：執行時間、裝置能耗、記憶體用量、電磁輻射等
絕大多數密碼學演算法實現，如AES加密演算法的標準實現等，都是基於黑盒安全模型的。
這意味著，即便對應的密碼學演算法和協議設計達到了理論能力的上限，資訊理論安全在黑盒安全模型要求的假設被打破的前提下，依舊可能洩露隱私資料。
反過來講，對於受控的業務環境，可以保證沒有攻擊者能夠進入機房，或者難以透過其他方式遠端獲得這些中間狀態資訊，而且對應軟硬體模組的配置和使用都正確，那麼對應的技術方案還是安全的。
考慮到隱私和效率的取捨，黑盒安全模型下的技術方案，工程實現相對複雜度低，能夠提供高效的系統實現，可用於中間狀態資訊洩露風險低、可控部署環境中的業務場景。
2. 灰盒安全模型
小華吸取了上次的教訓，最佳化了加密演算法的實現，遮蔽了執行時間、裝置能耗等常用中間狀態資訊洩露。新的方案似乎生效了，攻擊者之前部署的木馬無法獲得有效資訊來破譯小華的私密資訊。
小華的最佳化一定程度上降低了隱私保護技術方案對於部署環境的信任要求，相比之前的黑盒安全模型，這裡的安全模型為灰盒安全模型, 允許一定程度的中間狀態資訊洩露。
灰盒安全模型，要求技術方案能夠防範由於常用中間狀態資訊而導致的隱私資訊洩露。常用中間狀態資訊，一般指技術方案執行過程中，容易從外部觀察到的各種物理訊號，如執行時間、裝置能耗、電磁輻射、聲波訊號等。這一類的攻擊通常被稱為側通道攻擊、旁路攻擊，或統稱為灰盒攻擊。
為了應對這些灰盒攻擊，需要在原先黑盒安全工程實現的基礎上改寫演算法，使得在不同輸入下，所需防範的物理訊號表現相同。以最常見的執行時間分析攻擊為例，灰盒安全模型下，對於所有的輸入，技術方案的執行時間總是保持均等，以此避免由於執行時間存在差異，而洩露關於隱私資料的資訊。
然而，這一類灰盒安全技術方案在系統效率上的副作用也很明顯。即便某些執行路徑可以更高效地執行，也需要特意降低其效率，使之與業務邏輯中效率最差的一條執行路徑相匹配，以此確保執行過程使用的時間、消耗的能量等外部可觀測物理訊號，在任意輸入下都不表現出顯著差異。
由此可見，灰盒安全技術方案的執行效率總是由業務邏輯中效率最差的一條執行路徑來決定，這對系統效率的最佳化帶來了一定的挑戰。
相比黑盒安全模型，灰盒安全模型對於部署環境的信任要求更接近現實情況，一定程度上考慮了內部人員風險等原本只能透過治理手段才能防範的隱私風險，具備更實用的抗攻擊能力。
灰盒安全模型下，技術方案的應用主要用於防範內部人員風險，或者在不完全可信的外包環境中部署執行業務。
3. 白盒安全模型
好景不長，攻擊者發現之前部署的木馬失效之後，升級了木馬程式，小華的灰盒安全方案並不完美，攻擊者獲得了技術方案執行過程中的內部變數值，小華的私密資訊再次遭到破譯。
灰盒安全模型雖然對中間狀態資訊做了一定的保護，但無法保證所有的中間狀態資訊都能得到有效保護。如果能夠實現這一點，就達到了工程層面中最強的白盒安全。
回到定義黑盒安全模型的公式，隱私技術保護方案可以抽象為關於隱私資料x的一個函式y = f(x)。在白盒安全模型下，除了x之外，攻擊者可以獲得y和f(x)在運算過程中產生的任何中間狀態資訊。
白盒安全模型假定執行環境完全對攻擊者透明，聽起來效果很玄幻。但金鑰如何保護？明文輸入不是直接就被看到了嗎？面對如此強大的攻擊者，如何才能保護隱私資料的安全呢？
效果確實很玄幻，目前現有研究對白盒安全模型的定義做了一定的弱化，通常會把保護目標限定為即便攻擊者控制了整個執行環境，也無法輕易透過記憶體讀取等方式提取出金鑰。
為了實現白盒安全，需要在灰盒安全的基礎上進一步打亂混淆金鑰的儲存方式並改寫演算法，讓正確的金鑰能夠在執行過程中被間接使用。這一工程安全要求進一步提升工程實現的複雜度，例如，AES加密演算法的白盒安全實現要比黑盒安全實現慢10倍以上。
儘管白盒安全模型下的大部分技術方案目前尚不成熟，在方案可用的前提下，對於需要在不可控的公開環境中部署的業務，如公共物聯網應用，非常有必要考慮使用白盒安全技術方案，用以保護終端裝置中的金鑰、控制隱私資料的洩露風險。
正是：密碼巧妙理論無破綻，工程精細實現需謹慎！
工程安全和理論安全是相互獨立的兩個維度，理論安全並不等於工程安全。再強的理論安全方案設計，也會因為不當的工程實現而導致前功盡棄。
瞭解密碼學工程領域的安全風險，對於實際應用落地和安全執行至關重要。企業在對基於密碼學技術的隱私保護技術方案選型時，需要理論聯絡工程，根據自身的業務場景和部署環境的特徵，選擇合適的安全模型，確保隱私保護技術方案的最終有效性。
在這兩論中，我們對密碼學技術選型中的理論能力邊界和工程能力邊界進行了分析。除了演算法理論和工程實現中的諸多安全假設，新興的量子計算和量子通訊也對隱私保護技術方案的有效性帶來了挑戰，具體分析，敬請關注下文分解。
