在受控環境中，防止意外錯誤和硬件故障足以實現安全行為。如果檢測到不可恢復的情況，系統可以切換到功能有限或沒有功能的狀態，但仍然是安全的。

在不受控制的環境中，各種形式的破壞都可能危及系統的安全。只有在生命周期的每個步驟都考慮安全性，才能防止這種情況發生，這些步驟包括：

1 威脅建模-在設計階段，必須識別安全需求。

2 安全的組件-軟件開發人員必須正確地實現安全需求。此外，他們必須以不向系統添加任何漏洞的方式實現所有其他需求。

3 安全的部署-軟件交付時（如從供應移到制造商），供應商必須提供軟件完整性和真實性的檢查機制。

4 主動維護-在產品的生命周期內，制造商必須糾正組件使用中發現的漏洞。

5 安全更新和啟動-在更新系統時，產品制造商必須確保更新軟件的完整性和真實性。

1. 威脅建模

創建安全系統的第一步是識別系統資產。產品制造商使用威脅建模來分析攻擊者如何威脅這些資產。

威脅建模必須集成到設計過程中，并在所有抽象級別上執行。因此，在定義高級需求時，軟件架構師識別進一步的抽象威脅。這些威脅會導致額外的安全需求，以減輕這些威脅。該分析將集成到隨后的每個開發步驟中。

嵌入式系統必須保護：

?系統安全：大多數類型的攻擊都會影響系統的安全性。

?系統可用性：如果攻擊者可以關閉系統，則客戶將無法使用設備。

?商業秘密：如果攻擊者可以訪問固件，他們就可以獲取其包含的商業秘密。

?法律遵從性：如果攻擊者可以導致系統違反法律（發送垃圾郵件，監視別人），這將對產品制造商造成法律影響。

?公司聲譽：系統故障可能會給制造商帶來不好的影響。

一旦確定了系統資產，產品制造商就必須估計攻擊者為攻擊這些資產而愿意投入的成本和資源。基于這些信息，開發團隊就可以定義產品必須達到的安全級別。基于定義的安全級別，開發人員可以導出安全需求以最小化風險。

IEC 62443安全等級

IEC62443定義了5個安全級別（SL）對組件達到的安全級別進行分類：

?安全級別0：不需要特殊要求或保護。

?安全級別1：防止無意或意外的誤用。

?安全級別2：使用很少的資源、一般技能和簡單活動防止故意濫用。

?安全級別3：利用適度的資源、系統特定知識和適度的活動，防止復雜手段的故意濫用。

?安全級別4：通過大量的資源、系統特定知識和高度活動，防止使用復雜手段進行故意濫用。

按照功能安全標準開發系統時，安全級別SL-1不需要進一步的活動。術語“很少（few）”、“中等(moderate)”和“高(high)”并不能很好地定義更高的安全級別。對于安全級別的一般理解是：

?SL-2可以防止業余愛好者或憤怒的前雇員查閱有關安全和想攻擊的系統的公開信息。

?SL-3可以防止專業黑客通過勒索、出售漏洞或提取的信息來賺錢。

?SL-4可防范從公司或政府獲得大量資金支持的專業黑客組織。

IEC62443安全要求

IEC62443列出了為滿足安全級別組件必須實現的功能需求。例如，“與系統交互的人……”：

?SL-1:…須被識別和驗證。

?SL-2:…須唯一標識和身份驗證（沒有共享的管理帳戶）。

?SL-3:…果從不受信任的網絡訪問，必須通過多因素身份驗證進行唯一標識和身份驗證。

?SL-4:…須在所有網絡上通過多因素身份驗證進行唯一標識和身份驗證。

安全區域

提高安全性的屏障（墻、門、保安、防火墻、虛擬化技術等）將系統劃分為區域，每個區域達到其組件的最低安全級別。雖然IEC62443主要解決自動化和控制系統中的操作技術安全問題，但定義的安全級別對于任何有關安全的討論都是有價值的。

2. 安全的組件

實現安全系統的第二步是確保每個組件的設計和實現都是安全的，并為其他組件提供安全的接口。組件開發人員必須遵循“設計安全”的原則，考慮適用的安全標準，并將威脅建模的結果納入設計過程的每個步驟。

接口約定

除了正確實現組件的功能需求外，安全性還依賴于對所使用的其他組件的約定的嚴格遵守。在這種情況下，約定意味著組件對其調用者的需求。

例如:

?從內存池中取出的每個內存塊都將返回到相同的內存池中。

?函數的參數不能為零。

?需在臨界區內調用函數。

對調用者施加這樣的限制有很多原因（性能、靈活性、可移植性等），系統的安全性要求滿足這些約定。

執行期望

在實現新組件時，開發人員應該通過盡可能多地驗證約定的遵從性來提高安全性。由于軟件無法在運行時驗證所有約定，組件開發者必須在相應的文檔中清楚地描述剩余的未檢查的期望。組件用戶可以遵循這些約定，并使用各種軟件開發技術（如評審、靜態分析、測試等）來證明對約定的遵從性。

通信協議驗證

實現通信端點的組件必須確保所有通信消息符合商定并記錄的協議。

具體來說，這意味著要驗證每條消息字段的類型、值范圍、大小和編碼，還要驗證元數據，如每次消息的數量、發送方地址和消息的預期順序。軟件必須根據安全列表檢查枚舉，而不是從拒絕列表中排除項目。對違反協議的反應必須設計成不可濫用。

隔離組件

有時，開發團隊希望使用與產品的目標安全級別不匹配的組件。在這種情況下，可以在具有受限的隔離環境中運行該組件。一種方法是使用內存保護單元限制內存訪問，并使用搶占式調度器保證運行時間。組件中漏洞造成的損害將被限制在孤立的環境中，不會影響系統的其余部分。

安全檢查表

使組件安全的第一步是確保它具有相對簡單的API，該API指導用戶如何正確使用它。這樣的組件需要詳細的、最新的文檔，包括安全手冊：checklist是用戶必須采取的確保安全使用組件的所有步驟的清單（例如“運行此驗證”，“使用這些選項進行編譯”或“在此常量中插入公鑰”）。

加密算法

系統的安全性很可能基于某些加密操作，用于加解密或簽名和校驗和的生成和驗證。這些加密操作僅在以下情況下提供安全性：使用了最先進的算法，可以熟練地實施，將來可以被更安全的東西取代。

很少有人具有相應知識和思維來設計好的加密算法。在密碼分析專家花了數年時間仍未破解成功之后，新的算法被認為是安全的（至少暫時如此）并公布。

安全地實現算法幾乎同樣棘手。有無數的障礙需要克服，從選擇適當的填充方案到防止定時攻擊或在正確的模式下使用加密原語。

依賴信譽良好的第三方的解決方案是一種被廣泛接受的最佳實踐。

系統配置

如果嵌入式設備具有影響其安全性的配置參數，則其應該具有默認的安全值。例如，密碼保護接口應該具有唯一的強密碼，或者在設備運行之前強制用戶修改密碼。

使用默認密碼并要求用戶更改密碼是遠遠不夠的。類似地，系統設計必須默認啟用加密，而非建議用戶稍后啟用。

系統日志記錄

記錄與安全相關的事件對于安全漏洞審計和分析至關重要，但很難實現。日志的完整性和機密性是產品制造商在威脅建模中必須分析的安全資產。

對于安全漏洞分析，希望在日志中包含盡可能多的信息和細節。然而，嵌入式設備中的系統資源限制了這個決策。如果不能保證協議的機密性，很多有價值的信息會泄漏。此外，一些法律也會限制記錄個人數據或要求在短時間內刪除這些數據。

開發團隊必須考慮的另一個方面是日志泛濫。如果攻擊者做了一些生成大量日志記錄的操作，那么不相關的信息可能會覆蓋關鍵信息。

在設計安全日志記錄方案時，要考慮到日志通常是設備制造商和設備所有者之間的責任案件中的證據，設備所有者可能對操縱日志感興趣。

3. 安全的部署

實現安全系統的第三步是確保編譯過的代碼和源代碼以及所有文檔存儲在安全介質上，并通過安全通道傳輸。在文件傳輸到嵌入式系統之前，攻擊者可以通過修改部分設計、代碼或二進制文件攻擊系統。

IT環境

攻擊者可以通過訪問或操縱開發人員的機器、帶有源代碼管理系統的服務器或在傳輸過程中操縱軟件來實現攻擊。防止開發者機器和服務器被操縱的措施：

?適當的IT權限管理

?定期更新所有使用的軟件

?限制物理訪問

?安全策略（例如，員工不在電腦前時必須鎖上電腦）

軟件傳輸

防止軟件在傳輸過程中被操縱的措施包括：

?使用PGP或X.509證書建立一個安全的通信通道，對所有通信進行簽名（和加密）。

?在通過電子郵件發送信息的同時，通過不同的通道（電話、信件、加密聊天等）傳遞加密安全的指紋。

?使用通過TLS、X.509證書、身份驗證和授權保護的數據傳輸門戶。

4. 主動維護

實現安全系統的第四步是確保所有組件在運行期間保持安全。

在對協議、密碼學和庫的研究中，隨時可能發現重大漏洞，產品的最終用戶必須更新其安全系統。軟件組件供應商必須建立一個系統，將發現的漏洞通知所有客戶。庫用戶必須能夠接收這些信息，以便在他們的系統中創建和部署軟件更新。

5. 安全更新和安全啟動

實現安全系統的第五步是確保在系統上執行的所有軟件的完整性和真實性，原則上可以通過下列方式：只有制造商可以安裝軟件，更新過程是安全的，啟動過程是安全的。

如果最終用戶無法更新軟件，則必須禁用具有已知漏洞的系統，并用改進的設備替換。在某些情況下，這可能是一個可行的解決方案，但通常的嵌入式系統需要一種方法來安裝新的固件。

如果攻擊者獲得對嵌入式系統的物理訪問權限，就有可能操縱其固件。在這種情況下，引導過程必須是安全的。安全更新過程對啟動時間沒有影響，適用于大多數嵌入式系統。這兩種機制都必須確保應用程序：

?固件真實性：可信方創建了固件。

?固件完整性：沒有其他人修改固件。

?固件版本：更新必須提供比已安裝的固件更新的版本（防止回滾到易受攻擊的舊版本）。

產品制造商應使用數字簽名方案來驗證固件的真實性。消息驗證碼（MAC）提供相同級別的安全性，但需要軟件提供商和嵌入式設備之間共享密鑰。多個設備不應使用相同的共享密鑰。

該產品需要認證方案的信任根。這個信任根是一個證書或公鑰，嵌入式系統可以用它來驗證固件的簽名。

身份驗證方案通常還驗證固件的完整性。

最后，引導代碼必須檢查軟件的版本。引導代碼將固件版本號存儲在無法篡改的安全位置。引導代碼不會安裝或引導版本號較低的固件。

安全更新

在安全更新方案中，固件在接收到軟件后對其進行驗證，并將其存儲在可信存儲區域（內部flash）中。設備在后續引導中使用更新和驗證過的軟件。更新過程的挑戰包括完整的固件通常不適合臨時通信內存，攻擊者可能會斷開電源并阻止安全檢查的執行。

安全啟動

在安全引導方案中，引導代碼在每次重新引導時加載并驗證軟件，這允許我們將軟件存儲在不安全的介質上（外部閃存，SD卡，網絡服務器等），簡化了更新過程并降低了硬件制造成本。但需要更多的內存，并且每次重新啟動需要更長的時間。

引導代碼仍然需要可信內存存儲固件加載程序的和信任根（用于驗證固件的加密密鑰）。

復位后，引導代碼將固件加載到RAM中，驗證其真實性、完整性和版本，對其進行解密，并在RAM中執行。

如果應用程序存在允許攻擊者修改引導代碼的安全漏洞，那么攻擊者就可以完全控制設備。有幾種硬件方式可以防止這種攻擊：

?一次性可編程（OTP）引導記錄鎖定引導代碼或信任錨的校驗和。

?硬件安全模塊（HSMs）是專用的協處理器，具有更高的權限和防篡改存儲。

?帶密鑰存儲的加密協處理器允許使用密鑰（用于解密或驗證），同時防止任何系統部分讀取或更改密鑰。

為了使用這種硬件支持，引導代碼通常配備了一個三階段的引導過程：

?硬件驗證引導管理器和信任根。

?引導管理器驗證并執行引導加載程序。

?引導加載程序加載、驗證、解密并執行應用程序。

引導加載程序和引導管理器是分開的，引導管理器盡可能簡單，不太可能包含錯誤，只有在極少數情況下才需要更新。引導加載程序包含所有復雜的設備驅動程序和網絡協議，因此它更有可能包含錯誤。由于不涉及硬件，所以更新引導加載程序更容易。

結論

在不斷變化的威脅環境中，在設計階段考慮產品的安全性至關重要。本文提供了對軟件開發挑戰的概述和見解。這些知識將幫助你從產品的規劃階段開始，在快速發展的威脅環境中確保產品的安全性和完整性。