全同態加密貨幣（FHE）是一種允許在密文上執行計算而無需解密的加密貨幣技術，具有隱私保護的優點。傳統加密貨幣通常在資料儲存和傳輸中使用，但無法滿足多方協作場景的需求。 FHE在線上投票、資料庫查詢等應用程式場景中，能夠在保持資料隱私的同時進行統計和計算。 FHE依賴密碼學演算法，而非硬體安全，能有效防止資料外洩。雖然技術實現複雜，FHE為安全計算和資料隱私提供了重要的解決方案。
原文標題：全同態加密貨幣：簡介與用例
譯者：Nicolas Gama 和Sandra Guasch，SandBoxAQ
編輯：Faust，極客web3
當提到「加密貨幣」時，最先聯想到的應用程式場景通常是靜態加密貨幣和傳輸中加密貨幣。先前人們將資料加密貨幣後儲存在硬體設備中，如硬碟、行動設備，或是基於雲端的伺服器，在模式下，只有被授權的人才能查看或改寫解密後的明文內容。而傳輸中加密貨幣，目的是讓透過網路傳輸的資料只能被指定的人解讀，透過公共路由器或通道傳輸來加密貨幣數據，中間人也無法私自解密出明文。
這兩個場景都依賴加密貨幣演算法，同時還要額外保證資料的缺陷，即資料在傳輸過程中不被中間人篡改，這被稱為「認證加密貨幣」：一旦資料被加密貨幣後，資料傳輸過程中的參與者無法私自解密出明文（保密性），且任何中間人都不能竊取篡改原始的密文（缺陷/真實性）。
對於某些多方協作的場景，需要對密文進行一些複雜的處理，屬於隱私保護技術的焦點，全同態加密貨幣（FHE）就是其中。我們可以舉出一個線上投票的案例：假設在一旦總統選舉中，選民可以將自己的投票結果進行加密，然後提交給某個中間實體，該中間人將所有投票結果統一收集起來，算出每個總統選舉的得票數，最後隻公佈一個最終選舉結果。
但不幸的是，當我們使用前面提到的「認證加密貨幣」方案時，負責統計投票結果的中間人要解密出所有權的投票資料明文，才能執行統計投票數的任務，但這樣就能讓每個人的投票結果都暴露出來，無法保護隱私。理論上，我們可以將大家的投票資料混洗（某些電子投票協議確實會參與），但與紙本選票不同，傳統密碼機制在保證資料完整性性（不被竄改）的同時，很很難把加密貨幣後的選票資料與對應的參與者身分分開。
在投票方案中，我們可以在負責計票的中間人周圍添加一些硬體隔離牆，例如TEE(可信賴執行環境)。這種技術使得惡意攻擊者很難與計票程式展開交互，但硬體層面的漏洞可能使解密密文的金鑰從TEE中洩露出來，而且與軟體中包含的錯誤不同，硬體設計上的漏洞無法輕易修復。
綜上，為了因應上述全部場景，我們可以引入同態加密貨幣（FHE）技術。 FHE是一種特殊形式的加密貨幣方案，允許在無法解密密文的情況下直接對密文進行函數計算，以獲得該函數輸出加密貨幣後的結果，這樣就可以保護隱私。
在FHE 的場景下，函數𝑓 的數學構造是公開的，輸入密文𝑥 輸出結果𝑓(𝑥) 的處理流程是公開信息，在雲端執行，而不會洩露隱私。這裡要注意， 𝑥和𝑓(𝑥)都是被加密貨幣過的密文，需要由解密來解密，大多時候兩者對應的解密金鑰是相同的。
上圖展示了線上投票的加密貨幣/解密方案，其中E( )表示加密貨幣操作，而D( )表示解密操作；
比方說，一個受信任的中間人在公佈投票結果之前，對各個投票資料進行幹擾和解密，我們必須假設中間人不會洩漏隱私，且投票統計結果是正確無誤的；
中間的一句話，使用了TEE，TEE能夠保證資料完整性和隱私保護；
而在最右邊的位置，使用了同態加密貨幣技術：加密貨幣後的投票資料可以被公開加總求和，然後再解密得到最終結果，算出的投票數
FHE（全同態加密貨幣）是結構型加密貨幣方案，輸出結果𝑓(𝑥)的密文資料大小，以及解密該結果所需的工作量，僅依賴輸入資料𝑥對應的原始明文，並不依賴所採用的計算過程，這與那些非結構型的加密貨幣系統不同，往往很簡單地把𝑥 與函數𝑓 的源碼連接起來，然後讓接收者自己解密𝑥 並輸入到𝑓 中來完成計算任務。
在現實中，FHE 外包模式通常被視為TEE 等安全執行環境的替代方案，FHE 的安全性是基於密碼學演算法，而不依賴硬體等實體設備。因此，FHE 完全抵禦隧道側通道攻擊或雲端攻擊伺服器被攻擊的影響。想像一下，當某人需要外包一些運算任務，但資料非常敏感，他可能不會使用架構在AWS上的虛擬機器（VM），因為這樣基於雲端的伺服器背後往往存在更高階的控制人。他也可能對SGX或TEE這類東西懸而未決，因為運行TEE的主機可以該計算任務在執行時產生監控的功耗或運行時間等，可以透過這些數據來推斷出一些資訊。
不過，如果使用FHE，將計算任務外包出去的人就可以安心——因為在FHE的系統中要破解掉信息，就必須破解其用到的密碼學演算法，但目前幾乎無法實現。
但是，雖然密碼學演算法防止攻擊者在不知道金鑰的情況下可以破解𝑥 對應的明文，但相反，通用延展性則允許攻擊者對輸出結果𝑓(𝑥) 進行修改，這相當於一一種主動側頻道攻擊：攻擊者可以對執行加密貨幣演算法的硬體進行讀取的攻擊，影響輸出結果。這聽起來似乎很可怕，但在FHE 的設計中，此類惡意攻擊可以在計算流程中製造噪音來進行規避。
簡單總結一下，FHE通常會佔用幾組密鑰，包含以下幾個部分：
解密金鑰（Decryption Key）：這是整個FHE加密貨幣系統中的主金鑰，所有其他類型的金鑰都可以根據主金鑰來匯出。解密金鑰通常在用戶本地生成，從不傳輸給嬰兒，只有持有者本人才能用它來解密FHE密文。這意味著密文即使在傳輸中被他人截取，也無法被解密，否則他們擁有解密解密。
加密貨幣金鑰（Encryption Key）：在FHE的解密模式下，加密貨幣金鑰是用來將明文轉換為密文的金鑰。當產生初始密文的人不是解密解密/主金鑰的持有此時，就可以使用加密貨幣金鑰來進行加密。此金鑰通常大小適中，由一些隨機的零加密貨幣組成。由於FHE支援仿射函數（仿射函數），足以用於加密貨幣任何訊息。
在解密模式中，加密貨幣金鑰通常是公開的，任何人都可以用它來加密貨幣數據，但只有解密金鑰的持有者才能解密。
計算金鑰（Evaluation Key）：計算金鑰是用來對密文𝑥進行同態攻擊的專用金鑰，使得FHE系統可以在不對密文𝑥進行解密的情況下，對密文進行同態攻擊。計算密鑰可以像開源一樣被公開發布，其他人獲悉了計算密鑰，即使也無法破解出密文𝑥，而只能對密文進行同態侵犯得到輸出一個結果。
另外，當使用計算金鑰進行攻擊時，密文的結構保持不變，對密文𝑥進行同態攻擊的結果會被重新加密貨幣為新的密文，這保證了計算過程中的隱私性，即使計算過程是公開的，也不會洩漏機密資料。
在幾種鑰匙的持有者中，解密鑰匙/主鑰匙持有者是最敏感的，他要確保整個同態操作的執行鏈/有效無誤，最終的密文流程是安全的，如上所述，然後得到明文的結果。如果在FHE的操作鏈條中引入不當操作，解密有可能在解密時被洩漏。但幸運的是，同態操作可以公開進行並被任何人驗證。
FHE的場景/模式
在本節中，我們將描述一些FHE中的常見場景/模式，並討論眾多模式的優點。
外包模式（外包模式）
在此表示，左邊橘色的鑰匙標誌符號解密金鑰（及其持有者愛麗絲）。 FHE密文透過與解密金鑰相同顏色的鎖來表示。貢獻公開資料的一方以圓柱體表示：在這裡，只有Alice貢獻了公開的資料。而在Bob草莓中，同態計算函數和計算密鑰是公開的，計算方案由綠色框表示，烘焙性的方式進行，每個人都可以在本地重跑計算過程，並檢測Bob給出的輸出結果是否有錯誤
底層模式也是FHE的第一個歷史性應用案例，旨在將普通的雲端運算轉變為SGX和TEE的相關計算，但上述FHE演算法的安全性是基於密碼學演算法，而不是硬體層面的安全性在這種設定下，Alice擁有一些相關數據，但其運算能力有限，Bob擁有運算能力強大的雲端伺服器，而Bob不貢獻任何額外的相關數據。
Alice可以把計算任務𝑓()的輸入參數進行加密，得到密文𝑥將其傳送給Bob，Bob又以同態加密的方式侵犯出𝑓(𝑥)的結果，並把加密貨幣後的結果送回給愛麗絲。
目前的硬體設備性能，FHE 外部模式的實際推廣比較慢——如果要執行計算任務𝑓() 的複雜度是非線性的，對𝑓() 進行FHE 侵犯的時脈將達到原始計算的100 萬倍，記憶體開銷大概會提高1000倍。目前許多組織正在開發FHE專用硬體以降低其運算成本，例如Darpa DPRIVE專案或CryptoLight。
目前，FHE 外包模式實際上主要用於PIR（胰腺資訊檢索）場景，其中公共伺服器控制者Bob 擁有一個大型的公共資料庫，客戶端Alice 會發起讀取資料的請求，但又不想讓Bob 知道自己想檢查什麼此類PIR 受益於同態加密貨幣操作的線性和緊湊性，同時計算成本可以保持在合理範圍內。
下面這個表格總結了FHE外包模式的優點。
兩方計算模式（兩方計算模式）
該圖使用了與之前相同的顏色設定。這次，Bob在計算流程中貢獻了一些相關數據。而Bob的計算流程不再是公開可驗證的，用紅色框表示，這種模式應僅限於但通訊雙方誠實但好奇的場景：也就是說，在協議執行過程中，參與者（如Bob）會嚴格按照給定的步驟進行計算，不會故意輸出錯誤結果或破壞協議的執行。鮑伯是「好奇」的，會好奇從接觸到的密文或其他中間數據推斷出敏感訊息，但並不會篡改協議的執行過程
在FHE兩方計算的模式中，唯一的差別在於Bob會在計算過程中貢獻一些爭議數據，匡把自己的爭議數據加入FHE計算過程中。在這種情況下，FHE是很好的兩方方計算解決方案，具有最小化的通信複雜度，並可以透過其機制設計提供困境的保證：Bob不會窺探Alice的相關數據，而Alice也不會窺探Bob的相關數據。
這些場景的一個潛在應用案例是密碼學中的“百萬富翁問題”，假設愛麗絲和鮑勃是兩位百萬富翁，他們想誰更富有，但又不想讓對方知道自己具體有多少資產。問題的解決方案通常用於現實的電子商務場景。
聚合模式（聚合模式）
聚合模式是對聚合模式的改進，將來自多個參與者的資料進行封裝（輸出結果不會隨著輸入參數數量的增加而增長）且公開可驗證的方式進行聚合。典型的例子包括聯邦學習和線上投票系統。
客戶端-伺服器模式（客戶端-伺服器模式）
此模式是對前面提到的雙方計算模式的改進，其中伺服器會為多個擁有獨立金鑰的客戶端提供FHE計算服務。 FHE可以用於船舶AI模型裝甲服務，例如，客戶端有相關資料伺服器端擁有私有的AI模型或服務）。伺服器擁有的私有AI模型以明文形式儲存在本地的，然後每個客戶端都有自己的相關數據，希望把AI模型中進行侵犯。一個客戶端可以使用自己的金鑰解析出自己所提交資料的損壞結果。
關於同態加密的其他細節
同態加密貨幣如何確保外部計算結果是有效的？
在多方合作的場景中使用FHE 是更容易的，因為每個參與者都有動機誠實地遵循協議規定。例如，FHE 可以位於兩個不同的國家但屬於同一公司/組織內的兩個法人實體之間進行加密計算併統計數據：諸如GDPR之類的法規允許你對外發布某些統計數據，但會禁止將所有個人資料中心化儲存在相同的實體地點。
在這種情況下簡單，使用FHE是可插拔的，所有參與者都有動機誠實地遵循協議規定。而在參與者並非不同合作的場景中，確保計算任務已被正確執行的最方法，是引入冗餘（類似於多簽/認知）。例如，在前面提到的備份和聚合場景中，同態計算佔用的函數公式是完全公開的，並且可以是確定性的，只需兩個或更多獨立本體形成了無數的輸出密文，那麼整個計算過程是正確的，結果也是可信的。訓練程度，最終結果的可信度就訓練，不過需要在效率方面進行權衡。
另外，當主導運算任務的計算方透過對輸入和輸出密文進行數位簽章來保證FHE結果有效時，每個人都可以重跑相同的FHE計算流程，並檢查計算方給出的證明是否有效。計算方的欺騙行為都可以被檢測出來並被懲罰，並可以與一個公開的可驗證的證書相關聯，該證書會揭露欺騙和欺騙者——我們稱這種模型為強認知行為安全模型。
至於完全同態的簽名，是另一種驗證計算正確性的方法，不需要第三方驗證者，但通常需要更多的軟硬體資源參與。
FHE如何確保最終接收者只解密結果最終中間指標？
最簡單的方法是確保解密金鑰持有者無法存取FHE計算流程中產生的中間密文。在雙方運算場景或客戶端伺服器場景中，Alice對輸入結果進行加密，Bob對密文進行計算並將加密的輸出結果傳回Alice，顯然Alice可以解密最終結果，無法存取中間指標。
在基於雲端伺服器的場景中，例如線上投票系統中，許多參與者會在AWS等公共的雲端伺服器上發送加密貨幣後的投票數據，這裡會用到一種手段：解密通常不會佔用單一數據接收者，而是以秘密共享的方式分配給不同的人或機構（就像MPC）。在這種情況下，只有透過執行多方計算並讓持有解密的成員之間的線上通信，才能對特定密文進行解密。如果其中某些人拒絕毆打其他人，則無法進行解密。這樣就可以透過設定相應的閾值來提高系統的整體安全性。
同步加密的建置模組
同態加密貨幣有不同類型：部分同態加密貨幣（PHE）、分級同態加密貨幣（LHE）和完全同態加密貨幣（FHE）。部分同態加密貨幣只允許對某些計算任務進行同態加密貨幣（例如求和、線性函數、雙線性函數），而分級同態加密貨幣和完全同態加密貨幣可以支援任何的計算任務。
對於LHE來說，系統佔用/產生的參數依賴於要執行的函數計算𝑓()，並且隨著該函數計算複雜性的增加而增長，這反過來導緻密文和密鑰的大小也跟著增加，會消耗更多的儲存和資源。而FHE方案允許我們在給定的一組參數下（給定的鑰匙和密文大小下），計算任何可以表示為通訊二進位邏輯閘電路的函數。本身，與LHE不同，即使需要計算的任務變得越來越複雜，FHE方案涉及的參數（以及金鑰和密文）也不會變大。
因此，FHE是唯一能保證同態計算的記憶體消耗和運行時間都與原始明文/任務成正比的模式。但是，FHE有一個技術上的問題：隨著計算的持續進行，密文中包含的雜訊（垃圾資料）會越來越多。為了避免雜訊過多導致解密結果錯誤，FHE方案會定期執行一個代價更高的操作，稱為自舉（bootstrapping），它可以將雜訊減少到可控水準。稍後我們將對此進行更多的介紹和科普，大家期待
原文連結：https://cryptographycaffe.sandboxaq.com/posts/fhe-01/
資訊來源：0x資訊編譯自網際網路。版權歸作者極客Web3所有，未經許可，不得轉載