如今，只有懶人沒有寫過有關區塊鏈技術、加密貨幣及其有多酷的文章。 但本文不會讚揚這項技術；我們將討論它的缺點以及消除它們的方法。
在 Altirix Systems 從事其中一個專案時，出現了對來自區塊鏈外部來源的資料進行安全、抗審查確認的任務。 需要確認第三系統記錄的變化，並根據這些變化執行智慧合約邏輯中的一個或另一個分支。 乍一看，這項任務相當微不足道，但當參與流程的一方的財務狀況取決於其實施結果時，就會出現額外的要求。 首先，這是對這樣一個驗證機制的全面信任。 但首先要說的是。
問題在於區塊鏈本身是一個自治的、封閉的實體，因此區塊鏈內部的智慧合約對外界一無所知。 同時，智能合約的條款往往與真實事物的資訊（航班延誤、匯率等）有關。 為了使智能合約正常運作，從區塊鏈外部接收的資訊必須可靠且經過驗證。 這個問題透過使用Town Crier、DECO等預言機解決。 這些預言機允許區塊鏈網路上的智慧合約信任來自可信任網路伺服器的資訊；我們可以說它們是可靠資訊的提供者。
神諭者
想像一下，如果您最喜歡的足球俱樂部贏得了俄羅斯盃，那麼智能合約會將 0.001 比特幣轉移到您的比特幣錢包中。 如果真正獲勝，智能合約需要傳輸哪支球隊獲勝的信息，這就產生了一系列問題：從哪裡獲取這些信息、如何安全地傳輸到智能合約以及如何確保這些信息智能合約中收到的有效信息是否與現實相符？
當涉及資訊來源時，可以有兩種情況：將智慧合約連接到集中儲存比賽結果資訊的可信任網站，第二種選擇是一次連接多個站點，然後從大多數來源中選擇資訊提供相同的數據。 為了驗證訊息的正確性，需要使用預言機，例如Oraclize，它使用TLSNotary（TLS Notary Modification to Prove the Authenticity of Data）。 不過 Google 上關於 Oraclize 的資訊已經足夠多了，而且還有幾篇關於 Habré 的文章。今天我要講的是使用稍微不同的方式來傳輸資訊的 oracle：Town Crier 和 DECO。 文章描述了兩種預言機的運作原理，並進行了詳細的比較。
城鎮危機
Town Crier (TC) 由 IC3（加密貨幣和合約倡議組織）於 2016 年 CCS'16 上推出。 TC的主要想法：將訊息從網站傳輸到智慧合約，並確保TC傳遞的訊息與網站上的訊息相同。 TC使用TEE（可信任執行環境）來驗證資料所有權。 TC 的原始版本描述如何與 Intel SGX 一起工作。
Town Crier 由區塊鏈內部的部分和作業系統本身內部的部分（TC 伺服器）組成。
TC合約位於區塊鏈上，作為TC的前端。 它接受來自 CU（用戶智能合約）的請求並傳回來自 TC Server 的回應。 TC Server 內部有一個 Relay，它在 enclave 和互聯網之間建立連接（雙向流量），並將 enclave 與區塊鏈連接起來。 Enclave 包含 progencl，這是從區塊鏈發出請求並使用數位簽章將訊息傳回區塊鏈的程式碼，progencl 包含部分智慧合約程式碼並本質上執行其一些功能。
Intel SGX enclave 可以被認為是一個共享庫，其 API 透過 ecall 運作。 Ecall 將控制權轉移到飛地。 飛地執行其程式碼，直到退出或發生異常。 ocall 用於呼叫 enclave 外部定義的函數。 Ocall 在 enclave 外部執行，並被 enclave 視為不可信呼叫。 執行 ocall 後，控制權返回 enclave。
在Enclave部分，透過Web伺服器設定安全通道，Enclave本身與目標伺服器執行TLS握手並在內部執行所有加密操作。 TLS 庫 (mbedTLS) 和簡化的 HTTP 程式碼已匯出至 SGX 環境。 此外，Enclave 還包含根 CA 憑證（憑證的集合）來驗證遠端伺服器的憑證。 請求處理程序接受以太坊提供的格式的資料報請求，對其進行解密並解析。 然後它產生一個包含所請求資料報的以太坊交易，用 skTC 對其進行簽署並將其傳輸到 Relay。
中繼部分包括客戶端介面、TCP、區塊連結口。 需要客戶端介面來驗證 enclave 程式碼並與客戶端進行通訊。 用戶端使用 ecall 發送證明請求，並接收 skTC 簽名的時間戳記以及 att（證明簽名），然後使用 Intel Attestation Service (IAS) 驗證 att，並由可信任時間服務驗證時間戳記。 區塊連結口驗證傳入的請求並將交易放置在區塊鏈上以傳輸資料報。 Geth 是官方的以太坊客戶端，讓 Relay 透過 RPC 呼叫與區塊鏈進行互動。
TC與TEE配合使用，可並行運行多個enclave，將資訊處理速度提高3倍。 如果一個運行的enclave 的速度為15 tx/秒，那麼如果有20 個並行運行的enclave，速度會增加到65 tx/秒；作為比較，比特幣區塊鏈中的最大運行速度為26 tx/秒。
DECO
DECO（TLS 的去中心化預言機）在 CCS'20 上亮相，與支援 TLS 連線的網站合作。 確保資料的機密性和完整性。
DECO with TLS 使用對稱加密，因此用戶端和 Web 伺服器都有加密金鑰，且用戶端可以根據需要偽造 TLS 會話資料。 為了解決這個問題，DECO 在證明者（智慧合約）、驗證者（預言機）和網路伺服器（資料來源）之間使用三向握手協定。
DECO 的工作方式是，驗證者收到一條資料D，並向驗證者確認D 來自TLS 伺服器S。另一個問題是TLS 不會對資料進行簽名，TLS 用戶端很難證明該資料是來自TLS 伺服器S 。資料是從正確的伺服器接收的（來源困難）。
DECO 協定使用 KEnc 和 KMac 加密金鑰。 客戶端向 Web 伺服器發送請求 Q，伺服器 R 的回應以加密形式出現，但客戶端和伺服器擁有相同的 KMac，客戶端可以偽造 TLS 訊息。 DECO 的解決方案是對客戶端（證明者）「隱藏」KMac，直到它回應請求。 現在KMac分為證明者和驗證者－KpMac和KvMac。 伺服器接收 KMac 並使用金鑰部分運算 KpMac ⊕ KvMac = KMac 加密回應。
透過建立三次握手，客戶端和伺服器之間的資料交換將在安全的情況下進行。
說到去中心化的預言機系統，就不能不提到Chainlink，它的目標是創建一個兼容以太坊、比特幣和超級賬本的去中心化的預言機節點網絡，並考慮到模組化：系統的每個部分都可以更新。 同時，為了確保安全性，Chainlink 為參與任務的每個預言機提供了金鑰組合（公鑰和私鑰）。 私鑰用於產生部分簽名，其中包含他們對資料請求的決定。 為了獲得答案，有必要結合網路預言機的所有部分簽名。
Chainlink 計劃進行初步 PoC DECO，重點關注 Mixicles 等去中心化金融應用。 截至撰寫本文時，《富比士》上有消息指出 Chainlink 收購了康乃爾大學的 DECO。
對神諭的攻擊
從資訊安全的角度來看，考慮了對 Town Crier 的以下攻擊：
-
TEE 節點上的惡意智慧接觸程式碼注入。
攻擊的本質是：將故意不正確的智慧合約程式碼傳輸到TEE，因此，獲得節點存取權限的攻擊者將能夠在解密的資料上執行自己的（欺詐性）智能合約。 然而，返回值將使用私鑰加密，存取此類資料的唯一方法是在返回/輸出時洩露密文。
針對這種攻擊的防護包括飛地檢查目前位址處代碼的正確性。 這可以使用尋址方案來實現，其中合約位址是透過散列合約代碼來確定的。 -
合約狀態密文變更洩漏。
攻擊的本質是：執行智慧合約的節點的擁有者可以以加密形式存取 enclave 以外的合約狀態。 攻擊者在獲得節點控制權後，可以比較交易前後的聯繫狀態，並確定輸入了哪些參數以及使用了哪種智能合約方法，因為智能合約程式碼本身及其技術規範是公開的。
保護以確保節點本身的可靠性。 -
旁路攻擊。
一種特殊類型的攻擊，在各種場景中使用監控 enclave 記憶體和快取存取。 此類攻擊的一個例子是 Prime 和 Probe。
攻擊順序：- t0：攻擊者填滿受害者程序的整個資料快取。
- t1：受害者透過依賴受害者的敏感資料（加密金鑰）的記憶體存取來執行程式碼。 快取行是根據密鑰位值選擇的。 在圖中的例子中，keybit = 0，讀取快取線2中的位址X，X中儲存的資料載入到快取中，替換先前的資料。
- t2：攻擊者檢查哪些快取行已被逐出－受害者使用的行。 這是透過測量訪問時間來完成的。 透過對每個密鑰位元重複此操作，攻擊者可以獲得整個密鑰。
攻擊保護：Intel SGX 具有針對側通道攻擊的保護功能，可防止監控與快取相關的事件，但 Prime 和 Probe 攻擊仍然有效，因為攻擊者監控其進程的快取事件並與受害者共享快取。
因此，目前沒有針對這種攻擊的可靠保護。
與 Prime 和 Probe 類似的 Spectre 和 Foreshadow (L1TF) 等攻擊也是已知的。 它們允許您透過第三方通道從快取中讀取資料。 提供針對 Spectre-v2 漏洞的防護，可抵禦其中兩種攻擊。
對DECO來說，三向握手提供了安全保證：
- 證明者完整性：被駭客攻擊的證明者無法偽造伺服器來源訊息，也無法導致伺服器接受無效請求或錯誤地回應有效請求。 這是透過伺服器和證明者之間的請求模式來完成的。
- 驗證者完整性：被駭的驗證者不會導致證明者收到錯誤的答案。
- 隱私：被駭客攻擊的驗證程序僅檢查公共資訊（請求、伺服器名稱）。
在 DECO 中，只有流量注入漏洞是可能的。 首先，透過三向握手，驗證者可以使用新的隨機數來確定伺服器的身份。 然而，握手之後，驗證者必須依賴網路層指標（IP位址）。 因此，必須保護驗證者和伺服器之間的通訊免受流量注入。 這是透過使用Proxy來實現的。
預言機比較
Town Crier 是基於伺服器部分中的 enclave 工作，而 DECO 允許您使用三向握手和使用加密金鑰進行資料加密來驗證資料來源的真實性。 這些預言機的比較是根據以下標準進行的：性能、安全性、成本和實用性。
城鎮危機
DECO
表現
更快（0.6秒完成）
較慢（10.50 秒完成協議）
安全
安全性較低
更安全
成本
更貴
便宜一點
實際性
需要特殊硬體
適用於任何支援 TLS 的伺服器
速度表現：與DECO配合使用，需要三次握手，透過LAN建立時需要0.37秒，建立連接後交互，2PC-HMAC有效（每次寫入0,13秒）。 DECO 的效能取決於可用的 TLS 密碼套件、私有資料的大小以及特定應用程式證據的複雜性。 以IC3的二元期權應用為例：透過LAN完成協議大約需要10,50秒。 相比之下，Town Crier 大約需要 0,6 秒才能完成類似的應用程序，比 DECO 快約 20 倍。 在所有條件相同的情況下，TC 會更快。
安全：對 Intel SGX enclave 的攻擊（旁道攻擊）有效，並且可能對智能合約的參與者造成真正的損害。 對於DECO，與流量注入相關的攻擊是可能的，但是代理的使用可以將此類攻擊消除。 因此DECO更安全。
成本：支援Intel SGX的設備成本高於在DECO中設定協定的成本。 這就是為什麼TC比較貴的原因。
實際性：要與 Town Crier 合作，需要支援 TEE 的特殊設備。 例如，第六代英特爾酷睿處理器系列及更高版本支援英特爾 SGX。 DECO 允許您使用任何設備，儘管有使用 TEE 的 DECO 設定。 根據設定過程來看，DECO的三次握手可能需要一些時間，但這與TC的硬體限制相比並不算什麼，所以DECO更加實用。
結論
分別查看兩個神諭並根據四個標準進行比較，很明顯 Town Crier 在四分之三上不如 DECO。 從資訊安全的角度來看，DECO 更可靠、更便宜、更實用，儘管建立三方協定可能需要一些時間，並且有其缺點，例如需要使用加密金鑰進行額外操作。 TC 比 DECO 更快，但側通道攻擊漏洞使其容易失去機密性。 必須考慮到，DECO 是在 2020 年 4 月推出的，而且還沒有足夠的時間來考慮它的安全性。 Town Crier已經遭受了XNUMX年的攻擊，並且經過了多次測試，因此它在許多專案中的使用是合理的。
來源： www.habr.com