理想的嵌入式軟件一向兼具安全和防護設計。然而，“連網”給醫療、自動駕駛和物聯網(IoT)設備等安全關鍵的應用中，帶來了無法容忍程度的安全漏洞。

安全與防護的緊密結合，加上受到威脅程度的提高，使得開發者必須充分了解安全與防護之間的區別，而且從設計一開始就應用行業最佳實踐，才能確保兩者都被設計進產品中(圖1)。

圖1：過濾缺陷：理想的軟件和硬件設計要求在整個設計過程中采用多層次質量保證、防御和安全保護。(來源：Barr Group)

設計不佳的影響

隨著物聯網的崛起，系統現在很容易受到“遠程攻擊”的影響。最近的一起事件涉及索尼網絡安全攝像機被發現存在后門帳戶。這些端口可能被黑客用于使用僵尸網絡(botnet)惡意軟件感染系統，并發起更多攻擊。索尼因此開發了固件補丁，用戶可以下載來關閉后門。但實例中，還有許多編碼或設計錯誤是不可恢復且可能造成災難性后果的。

為了證明這點，兩名安全研究人員曾經以遠程無線方式 “黑”了一輛行駛中的Jeep Grand Cherokee，接管了儀表盤功能、方向盤、傳動和剎車制動系統等。當然，這一“劫持”并非惡意，而是經過司機許可，讓研究人員得以展示如何輕松地攻擊網絡運營商的互聯網絡有多么簡單。盡管如此，這次的黑客入侵實驗還是導致Chrysler召回了140萬輛車。

當然，系統不一定非要連到互聯網，才易受攻擊、不安全：編寫不佳的嵌入式代碼和設計決策已造成這樣的傷害了。例如1983年推出治療癌癥用的Therac-25放射治療機，就是一個關于系統設計應該避免哪些錯誤的經典研究案例。軟件錯誤、缺少硬件互鎖，以及整體性較差的設計決策等多種因素結合在一起，導致了致命的輻射劑量。

導致Therac-25造成致命事故的元兇包括：

?不成熟和不充分的軟件開發過程(“未經測試的軟件”)

?不完整的可靠性建模和故障模式分析

?未針對關鍵軟件進行(獨立)審查

?舊版軟件的重新使用不當

主要故障模式之一涉及頻繁溢出的測試例程中的1字節計數器。如果操作人員在溢出時為機器提供手動輸入，系統使用基于軟件的互鎖將會失效。

1996年6月，歐洲太空總署的火箭Ariane5(Flight 501)在發射后，偏離其預定的飛行計劃，而不得不引爆自毀，這是由于為了求快，而省略了溢出檢查所導致的。當一個保持水平速度的變量溢出時，就無法進行檢測并作出適當響應。

盡管如此，關鍵的程序代碼和安防漏洞仍然未得到審查。事實上，Barr Group的《2017年嵌入式系統安全與安防調查》顯示，在工程師所進行的項目中，如果連接至互聯網的項目被黑客攻擊，就會整個掛掉：

?22％未將安全性能作為設計要求

?19％沒遵循編碼標準

?42％根本沒有或只偶爾進行代碼審查

?48％的人未對其在互聯網上的通信進行加密

?超過33％未執行靜態分析。

了解安全與防護的真正意義，是朝著彌補這一局面邁出的重要一步。

定義安全和防護性

安全和防護(safety & security)這兩個詞經常被混用。有些開發者經常會有這樣的誤解：如果能編寫出好的代碼，那么項目就將是安全且受保護的。但顯然不是。

一個“安全”的系統是指：在正常運行過程中，系統本身不會對用戶，或其他任何人造成傷害的系統。“安全關鍵”(safety critical)系統是一種在故障時，可能導致傷害或傷亡的系統。因此，設計者的目標就是盡可能確保系統不出故障或者癱瘓。

另一方面，“防護”主要關注于產品在授權用戶使用其資產的同時，也防范未經授權的接入(如黑客)的能力。這些資產包括流動或動態數據、代碼和知識產權(IP)、處理器和系統控制中心、通信端口、內存和具有靜態數據的存儲器。

現在應該變得較明朗了，雖然系統能加以防護，但并不一定自動具有安全性：危險的系統也可能與安全可靠的系統一樣具有防護性。然而，不具防護性的系統總是不安全的，因為即使一開始時它的功能是安全的，但其易于受到未經授權侵入的脆弱性，意味著它可能在任何時候變得不安全。

實現安全和防護設計

當談到設計安全時，有很多因素要考慮，正如Therac-25的例子一樣。然而，設計師只能控制其設計方面，而本文著重的是固件。

關鍵任務應用的一個很好例子是現代化汽車。這些車輛內可能有1億多行代碼，但卻掌握在經常缺乏訓練或分心的用戶(駕駛員)手中。為了補強這部分用戶的需求，以攝像機和傳感器，以及車對基礎設施(V2I)和車對車(V2V)通信的形式添加了更多的安全特征和代碼。代碼量不斷增加，而且是呈指數級增長！

盡管海量代碼使得這種系統的編碼和調試更加困難，但如果遵循一些核心原則，則可以省去大部分調試時間，例如：

?對實時性能、成本、可升級性、安防性、可靠性和安全性有影響的硬件/軟件分配

?實施容錯區域。

?避免單點故障(圖2)

?處理由代碼錯誤、程序本身、內存管理或虛假中斷引起的異常

?將溢出檢查包括在內(Therac-25和Ariane火箭省略了)

?清理來自外界的污染數據(使用范圍檢查和CRC)。

?在每一層級進行測試(單元測試、集成測試、系統測試、模糊處理、校驗和驗證等)

圖2：安全關鍵系統避免單點故障。(資料來源：美國卡內基梅隆大學教授Phil Koopman)

為安全起見，設計師或開發者需要熟悉用戶和設備認證、公鑰基礎設施(PKI)和數據加密的復雜性。除了向授權用戶提供資產和保護資產免受未經授權的訪問外，安全性還意味著系統在面對攻擊或故障時不會做不安全或者無法預料到的事。

當然，攻擊有各種形式，包括基本拒絕服務(DoS)和分布式DoS(DDoS)。雖然開發者無法控制系統受到什么攻擊，但他們可以控制系統對攻擊的反應，且這種應對認知必須在全系統范圍內實施。系統最薄弱的環節決定了系統的整體安全程度，而假設攻擊者會發現該薄弱環節才是明智之舉。

針對薄弱環節的示例之一就是遠程固件更新(RFU)，可通過設備的遠程固件更新特性對系統進行攻擊。此時的系統十分容易受到攻擊，所以配備防范策略是明智之舉，例如：讓用戶選擇是禁用RFU，還是加載需對后續圖像進行數字簽名的更新。

這看起來似乎與直覺想法相反，但密碼學基本不會是最弱環節。相反，攻擊者會尋找由于實施、協議保護、API、用例和側信道攻擊等其它脆弱的攻擊面。

在這些領域投入多少工作、時間和資源，取決于防護威脅的類型，每一種威脅都有具體的防范措施。開發者可以采取如下一些常見舉措來提升產品的抗攻擊能力：

?使用無外部存儲器的微控制器

?禁用JTAG接口。

?實施安全啟動。

?使用主密鑰生成每個單元的設備專用密鑰

?使用目標代碼混淆

?實施開機自檢(POST)和內建自測試(BIST)

說到“混淆”，有一種理論提倡“隱藏式防護”(security through obscurity)。但若只依賴該想法，卻可能致命，因為每個秘密都會產生一個潛在的“軟肋”。無論是通過社會工程(social engineering)、不滿的員工，還是通過自卸和逆向工程等技術，秘密遲早都將不再是秘密。當然，隱藏式防護自有用處，例如讓密鑰保有秘密。

確保安全和防護

雖然有許多技術和技巧可以幫助開發者和設計師實現高度的安全性和防護性，但是有一些基本步驟可以確保系統在盡可能合理的情況下進行優化。首先，基于“久經考驗”的編碼規則、功能安全、行業和特定應用標準進行設計。這些準則包括MISRA和MISRA-C、ISO 26262、汽車開放系統架構(Autosar)、IEC 60335和IEC 60730等。

采用像MISRA這樣的編碼標準不僅有助于規避錯誤，還可以使代碼更易閱讀、一致及可移植(圖3)。

圖3：采用像MISRA這樣的編碼標準不僅有助于規避錯誤，還可以使代碼更易閱讀、一致及可移植(圖3)。(來源：Barr Group)

其次，使用靜態分析(圖4)。這涉及分析軟件，而非執行程序。它是種象征性執行，所以本質上是模擬。相比之下，在目標平臺上運行實際的代碼時，動態分析將會發現缺陷。

圖4：靜態分析工具運行源文件的“模擬”、語法和邏輯分析，并輸出警告而非目標文件。(來源：Barr Group)

雖然靜態分析并非靈丹妙藥，但它確實增加了另一層保證，因為它能很好地檢測潛在的錯誤；例如使用未初始化的變量、可能的整數溢出/下溢以及有符號和無符號數據類型的混用。此外，靜態分析工具正在不斷改善中。

通常，靜態分析意味著使用專用工具(如PC-Lint或Coverity)，但開發者還應考慮重新分析自己的代碼。

第三，進行代碼審查。這將提高代碼的正確性，同時也有助于可維護性和可擴展性。代碼審查還有助于召回/保修維修和產品責任索賠。

第四，進行威脅建模。從使用攻擊樹開始。這要求開發者像攻擊者一樣思考并執行以下操作：

?確定攻擊目標：

o每次攻擊都有一棵單獨的樹

?對于每棵樹(目標)：

o確定不同的攻擊

o確定每次攻擊的步驟和選項

值得注意的是，若從多個角度進行此類分析，則可大幅提高其效益。

誰有時間把它做對？

顯而易見，執行上述四個基本步驟就能輕松地減少錯誤，并增加安全性和防護性；但這需要時間，因此，開發者必須進行相應的時間預算。雖然項目規模不同，但重要的是必須盡可能實際。

例如，添加15%到50％的設計時間，以利于代碼審查。一些系統需要完整的代碼審查；有些不需要。靜態分析工具可能需要10到數百小時進行初始設置，但一旦進入開發過程的某一部分或階段，產品開發就無需額外時間進行產品開發了，他們最終都通過更好的系統獲得回報。

連網技術讓嵌入式系統設計增加了新的顧慮，它需要特別強調安全性和防護性。對這兩個概念的詳細了解、加上在設計周期之初就適當地應用最佳實踐，能大大提高產品的整體安全性和防護性。這些最佳實踐包括：采用編碼標準、使用靜態分析工具、代碼審查和威脅建模。