工控網首頁
>

應用設計

>

IoT 安全系列博文第三篇 軟件更新安全:常見的錯誤

IoT 安全系列博文第三篇 軟件更新安全:常見的錯誤

By Toradex Jon Oster

這是我們關于 OTA 軟件更新的 7 部分系列文章的第 3 篇。 在第 1 篇中,我們向您介紹了能夠遠程交付軟件更新的所有重要原因,在第 2 部分中,我們介紹了軟件更新系統危險的所有原因。 今天,我們將會探討保護您的軟件更新系統的方法,這些方法乍一看似乎是安全的,但實際上并非如此,每個示例都有現實世界中著名的故障。

軟件更新系統的組成部分

讓我們從最簡單的系統開始。 有一個設備,它知道它可能需要更新。 為簡單起見,我們還假設,更新是以單個文件的形式進行,并且設備知道它所需文件的名稱以及服務器的地址,我們稱之為存儲庫,在這個里面設備能夠找到需要的文件。然后設備可以訪問存儲庫,請求文件,下載并以任何可行的方式安裝它:

在設計軟件更新系統時,我們需要解決的最基本問題是:設備如何確信它收到的更新是可信的? 這是一個非常重要的問題,在物聯網中則顯得尤其困難,在大多數情況下,我們希望自動完成更新或在用戶同意的情況下進行。我們通常不想要設備的用戶來判斷推送給他的更新是否可信。

讓我們看看我們可能會選擇的一些常見方法,以及這些方法存在的問題。

選項 1:驗證存儲庫,設置安全通道

攻擊者可能具備的一項常見能力就是攔截流量或冒充存儲庫。因此,只要我們可以確保設備能夠驗證其正在與之通信的存儲庫是真實的(并且可以在整個“對話”中持續驗證),那么它就可以安全地安裝所找到的更新文件。 而且由于我們已經有了一個完善的方法來做到這一點(我們一直依賴 TLS),所以我們達成目的了。

因此,您可以使用證書鏈,一直追溯到某個受信任的根證書頒發機構,以驗證服務器的身份,并使用 TLS 為接下來數據傳輸設置加密連接。這樣問題解決了,因為只要我們與正確的服務器通信并且有加密連接,我們應該沒問題,對吧?

不完全是。 有兩大問題。 首先,TLS 可能不會被破壞,但 TLS 所依賴的信任體系并不完美。曾多次發現根證書頒發機構發布證書以允許中間人攻擊。 例如,中國法國的國家證書頒發機構都被發現簽發了假冒 Google 域名的欺詐性證書。 2019 年的一項學術研究表明,欺詐性 TLS 證書也可以在網絡犯罪市場和暗網上隨處購買。

其次,存儲庫本身可能會受到入侵。由于存儲庫的密鑰用于簽署每個請求,因此需要將其保存在服務器上,而攻擊者可以從中竊取它。即使服務器的密鑰存儲在硬件安全模塊中并且無法被竊取,獲取服務器訪問權限的攻擊者仍然可以在其控制期間對連接的每臺設備安裝惡意軟件。這正是 2013 年 Ruby Gems 存儲庫所發生的事情,使大部分互聯網陷入恐慌。攻擊者利用了 rubygems.org 中的漏洞。幸運的是,當時攻擊者并沒有惡意,只是想引起 RubyGems 團隊的注意,以便他們修補漏洞。但是,如果他們愿意,他們可以發布 Rails 等流行的惡意版本,并接管(或竊取密碼)任何碰巧在 RubyGems 存儲庫遭到入侵期間構建的 Ruby on Rails 網站,這包括 Twitter、Airbnb 和 Hulu 等網站。

選項 2:簽署您的軟件

因此,很明顯我們不能僅僅依賴于驗證存儲庫的身份。那我們是否可以在將軟件更新放入存儲庫之前,就為其添加一個準許??? 每個客戶端都可以驗證它,這樣即使存儲庫被入侵,我們的用戶仍能夠保持安全。理論上這也是一種使用基于公鑰加密數字簽名很容易做到且非常安全的方式。我們生成一個離線密鑰,確保我們的客戶端擁有公鑰,并讓我們的軟件更新程序拒絕任何沒有有效簽名的程序。

什么是離線密鑰? 離線密鑰是未保存在任何連接到 Internet 的計算機上的密鑰。它可能是像 Yubikey 這樣的硬件設備,也可能是密鑰文件存儲在 USB 存儲設備上并被保存在某個地方,只在需要時才取出。您不能將離線密鑰用于 TLS 之類的東西,因為每次建立連接時都需要使用這些密鑰。但是您可以將離線密鑰用于很少發生的加密任務,例如簽署主要軟件版本。

這是 Red Hat 和 Debian 等主要 Linux 發行版采用的基本方法。(多年來進行了各種改進,但基本方法保持不變。)當您安裝操作系統時,它會提供有一個 GPG 密鑰并信任其可以自我更新。這使得更新軟件可以安全地分發到世界各地的存儲庫鏡像,而存儲庫不需要任何密鑰。

通過驗證存儲庫的解決了兩個問題。我們不再使用復雜的證書認證系統,現在只有一個密鑰,我們自己將其分發給客戶端。我們還可以防止存儲庫泄露,如果攻擊者控制了存儲庫并嘗試發送惡意更新,我們的更新客戶端將拒絕它,因為它沒有有效的簽名。但這種方法也存在一些重大隱患。

最大的問題是關于密鑰分發和信任。如何確保您的客戶擁有正確的密鑰,如何在緊急情況下更新密鑰,以及如何確保離線密鑰確保離線,而不會在開發人員的筆記本電腦或編譯系統上泄漏? Red Hat (Fedora) Linux 和 Debian Linux 軟件更新程序都依賴 GPG 簽名(使用預分發的公鑰)都曾遇到過問題。 2008 年,Red Hat 發現他們用于簽署軟件包的服務器遭到入侵。對于 Debian,問題更為嚴重:原來用于為他們開發人員生成簽名密鑰的程序存在漏洞,這意味著需要替換大量的密鑰。從而在全世界范圍內引發一波安全通知和漏洞修復。在這兩種情況下,解決方案都是發布全球公告,要求系統管理員采取手動步驟更換密鑰,并掃描其系統以查找潛在漏洞。對于有專門的付費系統管理員的系統,這種方法可能是可行的。如果嵌入式系統中存在類似的密鑰泄露,則可能需要全球召回產品。

還要注意的是,在 Red Hat 的案例中,導致密鑰泄露的仍然是服務器遭到入侵。因此,即使密鑰不在軟件存儲庫中,它卻仍然存在與自動構建系統上。它并不能抵御存儲庫遭到入侵,而是將問題移到了整個鏈條中的上一個環節。

簡單軟件簽名的另一個主要問題是它只能防止惡意軟件。軟件更新系統,尤其是嵌入式軟件更新系統,需要應對更多類型的威脅。例如,經常會發布軟件更新來解決安全漏洞;如果攻擊者可以令客戶安裝舊版本的軟件,甚至只是確保他們沒有及時收到更新,這足以引發更嚴重的攻擊。(這些類型的攻擊分別稱為回滾和凍結攻擊。)

選項 3:采用上面的兩種方案

因此,我們現在研究了軟件更新系統采用的兩種主要方法,以及它們存在的問題。驗證存儲庫并使用加密連接 (TLS) 下載更新很容易受到證書頒發機構和廣泛分布信任鏈的所有問題的影響,并且在服務器遭到入侵的情況下根本無法保護您。使用離線密鑰對軟件進行簽名并禁止未簽名的更新可以解決存儲庫遭入侵的問題并避免證書頒發機構的問題。但在現實世界中,將簽名密鑰保持離線是不方便的,因此它們通??赡軙霈F在構建服務器(甚至開發人員的筆記本電腦)上,從而抵消了讓密鑰“離線”的優勢。盡管離線簽名避免了證書頒發機構和信任鏈的一些問題,但它也帶來了新的問題,尤其是圍繞密鑰分發的問題。

如果將兩者結合起來會怎樣呢?如果你已經看到這里,那么你可能已經有很多思路來解決這些問題,也許我們可以有一個主密鑰來簽署一個受信任的密鑰列表,并且我們可以在多個位置發布密鑰。我們甚至可以發布并簽署一份不應再被安裝的舊軟件鏡像列表,并讓我們的更新客戶端檢查該列表。您可能會認為,這里列出的問題似乎都不是很難解決的。你是對的!您完全能夠自己構建一個系統實現所有的更新服務,該系統整合諸多技術,如用于 GPG 密鑰撤銷的固定自托管密鑰服務器、預先配置的私有 TLS 證書頒發機構以及具有一些檢查所有簽名、密鑰、到期等規則的更新客戶端。

但是,如果您采用這種方式,會出現很多復雜情況,并且錯誤或漏洞可能會更容易出現。(閱讀 Microsoft 對允許安裝 Flame 惡意軟件的安全漏洞的解釋,了解即便是數十億美元公司在嘗試將整合這些獨立的技術時也可能會忽略一些事情。)您不希望您的更新系統由不同的技術方案簡單的拼湊而成,也不希望更新系統中的關鍵部分如密鑰分發有外部系統處理。

試圖將一些現有技術組合在一起的解決方案的另一個問題是故障模式可能無法預測,并且人類的天性有時會勝過理想的安全實踐。例如,您可能構建了一個使用 TLS 來驗證存儲庫并要求對軟件進行簽名的系統,但忽略了構建允許您撤銷和更換簽名密鑰的系統。幾年后,一位初級開發人員不小心將軟件簽名密鑰推送到了公共 github 存儲庫。您對召回您的設備進行修復以及更換密鑰進行成本效益分析,但從業務角度由于費用過高而被否決?,F在您只剩下 TLS 保護,所有上述問題?;蛘吣褂秒x線密鑰簽署發行版本,但幾個月后決定開始向客戶發布 nightly 版本,讓他們測試新功能。沒有人愿意每晚都手動對構建的軟件進行簽名。因此您開放讓 CI 流程訪問私鑰,這樣它就可以在夜間進行簽名?,F在該流程成為您整個設備集群的單點故障。

為了避免這些系統性問題,您從一開始就需要有一個能夠靈活管理密鑰的系統,并將其包含在更新系統中。您的設備應該有辦法確保每次檢查更新時都擁有關于密鑰、存儲庫位置等的最新信息。正確構建這些東西一件棘手的事情。但幸運的是,有 20 年的學術研究和實踐經驗可以指導您,包括既定的標準和最佳實踐,以及開源、經過時間考驗的軟件存儲庫和更新客戶端實現。

我很快將撰寫有關軟件更新規范的文章,以及我們在 Torizon 平臺中構建 OTA 更新系統時所做的決策。我們當然面臨一些挑戰:我們的客戶正在醫療設備和工業自動化等安全敏感領域中開發物聯網設備。他們有時還擁有異構集群,需要將不同的更新分配給不同的設備,并具有服務器端控制的能力。我們必須構建一個更新系統,確保離線密鑰的安全可穩定,以及客戶端可控的加密(在高安全性和高度監管的行業中必不可少),同時仍然提供 Toradex 眾所周知的易用性和使用體驗。請繼續關注我們是如何做實現的!

審核編輯(
王靜
)
投訴建議

評論

查看更多評論
其他資訊

查看更多

IoT 安全系列博文第二篇: 遠程更新的危險

為什么我們需要遠程自動更新互聯設備?

基于NXP iMX6ULL 擴展音頻解碼器 MAX98357A

導入C_C++應用到Torizon

深入了解TorizonExtension