將“垃圾進,垃圾出”問題應用在去中心化網(wǎng)絡上

降低這種風險的方法之一是將傳感器硬連接到制冷裝置中,使其無法被移動。但是,這種方法也不保險。比如說,可以在傳感器周圍包上一袋冰,這樣一來,就可以將卡車其他地方的溫度調(diào)高到要求范圍以上了。

1.png

本文來自微信公眾號“公鏈聯(lián)盟”。

在本文中,我們將討論一個經(jīng)常被忽略(大多是故意無視)的概念,即“真實世界中的數(shù)據(jù)如何與區(qū)塊鏈交互”。

與其他系統(tǒng)一樣,區(qū)塊鏈也同樣存在典型的“垃圾入、垃圾出”問題。區(qū)塊鏈基礎設施無法保證非鏈上生成的、不公開的數(shù)據(jù)的真實性,但不幸的是,世界上絕大多數(shù)數(shù)據(jù)都屬于此類數(shù)據(jù)。因此,如果有人(或設備)向區(qū)塊鏈提交了虛假數(shù)據(jù)的話,我們便沒有辦法確定該數(shù)據(jù)的真實性,最后只能將這些虛假數(shù)據(jù)永久地提交到區(qū)塊鏈歷史中。因此,如果把垃圾放到區(qū)塊鏈中,便也會從區(qū)塊鏈中得到垃圾。

如今,聲稱自己無意中忽略了這個問題的應用程序在市場上泛濫成災,它們往往都會借助額外的技術層來營造數(shù)據(jù)正確的假象。比如:

去中心化的數(shù)據(jù)市場:用代幣激勵公司將其數(shù)據(jù)掛牌出售。但是你怎么知道買來的數(shù)據(jù)是真實的呢?

隱私保護查詢:可以通過零知識證明來統(tǒng)計銀行高凈值客戶,因此,就可以在銀行不提供任何客戶信息的情況下得到統(tǒng)計結果——你怎么知道銀行的客戶數(shù)據(jù)庫不是捏造的呢?

對于公開的數(shù)據(jù)來說,你可以設計一款游戲,讓有財務風險的玩家就所提供數(shù)據(jù)的真實性相互進行挑戰(zhàn)(就像Chainlink或其他一些區(qū)塊鏈項目那樣)。但是,世界上絕大多數(shù)的數(shù)據(jù)都是非公開的。

那么,如何才能解決這個問題呢?關鍵是要從源頭上保證數(shù)據(jù)安全。

最實用的方法:確保數(shù)據(jù)來源可靠

如果數(shù)據(jù)不是從源頭處獲得的,而是通過第三方中介獲取的,那么如果中介不值得信任的話,數(shù)據(jù)的真實性也同樣不可信。在處理數(shù)據(jù)時,涉及的中介越多,需要付出的信任就越多,直到某一刻,當涉及的中介太多時,數(shù)據(jù)就和從隨機生成器中生成的沒什么兩樣了。

因此,我們的目標是要盡可能從靠近數(shù)據(jù)源的地方獲取數(shù)據(jù)。例如,與其從零售商的數(shù)據(jù)庫中獲取銷售數(shù)據(jù),不如從銷售硬件處獲?。慌c其從氣象網(wǎng)站上訂閱數(shù)據(jù),不如從氣象傳感器那里收集;與其閱讀橋梁運營公司的PDF報告,不如試著從安裝在橋梁上的攝像機和傳感器中獲取原始數(shù)據(jù)。

但是如何從源頭保護數(shù)據(jù)呢?既然世界上的大多數(shù)數(shù)據(jù)都是由設備生成或收集的,那么讓我們先研究一下如何保護設備生成的數(shù)據(jù)。這里,我們面臨三個可能會出現(xiàn)問題的故障點:

身份:你怎么知道是什么在生成數(shù)據(jù)?是像你預期的那樣來自溫度傳感器,還是來自惡意玩家的的隨機數(shù)生成器?

處理和傳輸:即使數(shù)據(jù)源是真實且可識別的,你又怎么知道數(shù)據(jù)在處理和傳輸過程中(例如從傳感器轉移到通信模塊的過程中)沒有被更改、損壞或徹底調(diào)包?

數(shù)字/模擬接口:即使身份、處理和傳輸都是安全的,你又如何防止有人通過接入虛假輸入信號,來改變設備收集數(shù)據(jù)的方式呢?

下面,讓我們來看看能做些什么,逐一解決上述問題吧。

身份

為了保護數(shù)據(jù)生成設備的身份,可以在設備中嵌入一組公鑰/私鑰,將公鑰公開,并且對硬件的實際輸出進行現(xiàn)場檢查,這才是能確保硬件提供可靠數(shù)據(jù)的切實可行的辦法。但這僅僅是最簡單的部分。

棘手的是,要如何確保這個身份不會被盜?我們可以使用一種名為安全元件(secure element,SE)的東西。該硬件可以在芯片內(nèi)生成公鑰/私鑰對,并且具有很強的防篡改能力。SE通常只做一件事:為消息簽名(提供身份證明的一種花哨講法)。如果你用過信用卡或智能手機的話,就已經(jīng)享受過安全元件的好處了。

處理和傳輸

為了保證數(shù)據(jù)處理和傳輸邏輯的安全,我們可以使用帶有安全啟動(secure boot,SB)的微控制器(MCU)。你可以把微控制器想象成一臺非常簡單的計算機。SB可以確保只有具有正確私鑰的實體才能將應用程序加載到MCU中??梢蕴崆芭c利害關系人共享應用程序邏輯和相關校驗和,或者干脆開源,這樣就可以在加載后對其進行驗證了。

更重要的是,當應用程序徹底測試完畢后,我們需要從應用程序和MCU禁用所有修改功能,包括固件升級。這是為了確保應用程序邏輯保持現(xiàn)在的狀態(tài)、不可變,甚至制造商也無法進行更改。

當然,這也存在明顯的弊端,比如應用程序無法再進行升級。但是,我們也因此獲得了真正的設備獨立性,不受外界干擾,其行為值得信賴、具有確定性且不可改變。

數(shù)字/模擬接口

這個問題非常棘手,并且不能使用嵌入在數(shù)據(jù)收集和中繼設備上的硬件來解決。一般來講,要確保接口不被中斷的話,就必須設計出新的機制,但這與應用程序有強相關性。我們可以用以下例子來進行說明。

假設你有一輛冷鏈物流公司的冷藏車,負責向當?shù)爻羞\送鮮魚。為了保證質量,魚必須全程保持在一定的溫度范圍內(nèi)。如果溫度太高,魚就會變質。如果溫度太低,魚的味道和口感就會變差。為了確保物流公司遵守合同規(guī)定的溫度范圍,超市在卡車上安裝了溫度傳感器。

但是,如果卡車司機把傳感器放在卡車前方的冰柜里,同時,為了節(jié)約能源成本而調(diào)高了制冷設備的溫度,那會怎么樣呢?傳感器不知道自己被挪動了位置,收集并上傳的溫度數(shù)據(jù)一直都處于合同規(guī)定范圍內(nèi)。就這樣,傳感器被騙了。

降低這種風險的方法之一是將傳感器硬連接到制冷裝置中,使其無法被移動。但是,這種方法也不保險。比如說,可以在傳感器周圍包上一袋冰,這樣一來,就可以將卡車其他地方的溫度調(diào)高到要求范圍以上了。

另一種更好(但更貴)的方法是在每包魚上都貼上防篡改的封條,然后在每包魚上都裝上一個溫度傳感器。這樣一來,如果司機想要取出溫度傳感器的話,就要破壞封條,這會違反合同的關鍵條款,并且這很容易就會被發(fā)現(xiàn)。

最后,要想解決數(shù)字/模擬接口的問題就需要進行大量的創(chuàng)新,解決方案往往具有高度的應用針對性。

當向企業(yè)客戶提供區(qū)塊鏈解決方案時,必須記住,如果存在更廣泛的設備獨立性問題,那么在應用于物聯(lián)網(wǎng)時,僅有區(qū)塊鏈是沒有用的。我們要確保這些邊緣設備生成的數(shù)據(jù)是真實可信的,并且完全不受外界影響。

THEEND

最新評論(評論僅代表用戶觀點)

更多
暫無評論