理想的嵌入式軟體一向兼具安全和防護設計。然而,「連網」對於醫療、自動駕駛車和物聯網(IoT)裝置等安全關鍵的應用中帶來了無法容忍程度的安全漏洞。

安全與防護的密切結合,加上受到威脅的程度提高,使得開發人員必須充份瞭解安全與防護之間的區別,而且從設計一開始就應用業界最佳實務,才能確保二者都被設計於產品中(圖1)。

20171222_Barr_TA31P1 圖1:過濾缺陷:理想的軟體和硬體設計要求在整個設計過程中採用多層次的品質保證、防禦以及安全保護(來源:Barr Group)

設計不佳的影響

隨著物聯網(IoT)崛起,系統如今相當易於受到「遠端行動」的攻擊。最近的一起事件涉及Sony網路安全攝影機被發現存在後門帳號。這些埠可能被駭客用於使用僵屍網路(botnet)惡意軟體感染系統,並發動更多攻擊。Sony因而開發了韌體增補程式,讓用戶下載後用於關閉後門程式。但還有許多實際的編碼或設計錯誤不僅無法恢復,還可能造成災難性的後果。

為了證明這一點,兩名安全研究人員曾經以遠端無線「駭」入一輛行駛中的Jeep Grand Cherokee,並接管車子的儀表板功能、方向盤、動力傳動與煞車系統等。當然這一駭入行動並非惡意,而是經過駕駛允許,讓研究人員得以展現駭入營運商的互連網路有多麼簡單。儘管如此,這次的駭客入侵實驗還是導致Chrysler召回了140萬輛車。

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

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

  • 不成熟和不充份的軟體開發過程(未經測試的軟體)
  • 不完整的可靠性建模和故障模式分析
  • 未針對關鍵軟體進行(獨立)審查
  • 舊版軟體的重新使用不當

主要的故障模式之一涉及經常超出測試程序的1-byte計數器。如果操作人員在發生溢位時為機器提供手動輸入,系統使用基於軟體的互鎖將會失效。

1996年6月,歐洲太空總署的火箭Ariane 5 (Flight 501)在發射後偏離其原訂的飛行計劃而不得不引爆自?,這是由於為了求快而省略了溢位檢查所致。當超出一個變量保持水平速度時,就無法進行檢測並做出適當回應。

儘管如此,關鍵的程式碼和安全漏洞仍然未得到審查。事實上,Barr Group的《2017年嵌入式系統安全與防護調查》(2017 Embedded Systems Safety and Security Survey)顯示,在工程師所進行的專案中,如果連接至網際網路的專案被駭客攻擊,就會整個掛掉:

  • 22%未將安全性能作為設計要件
  • 19%的人沒遵循編碼標準
  • 42%根本沒有或僅偶爾進行程式碼審查
  • 48%的人未對其於網際網路上的通訊進行加密
  • 超過33%的人未執行靜態分析

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

定義安全和防護性

安全和防護(safety & security)二詞通常混用。有些開發人員經常會有這樣的誤解:如果能編寫出好的程式碼,那麼專案就將是安全且受保護的。但顯然不是。

一個「安全」的系統是指:在正常運作過程中,系統本身不會對用戶或任何人造成傷害。「安全關鍵」(safety critical)的系統是是在故障時可能導致傷害或死亡的系統。因此,設計人員的目標就在於盡可能地確保系統不至於故障或癱瘓。

另一方面,「防護」主要關注於產品在授權用戶使用其資產的同時也防範未經授權存取(如駭客)的能力。這些資產包括流動或動態的資料、程式碼和智財權(IP)、處理器和系統控制中心、通訊連接埠、記憶體和靜態資料儲存。

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

實現安全和防護設計

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

任務關鍵的應用範例之一是現代化汽車。這些車輛內可能有多達1億多行程式碼,但卻掌握在一般缺乏訓練或分心的用戶(駕駛人)手中。為了補強這部份使用者的需求,甚至以攝影機和感測器以及車對基礎設施(V2I)和車對車(V2V)通訊的形式添加了更多的安全特性和程式碼。程式碼量正不斷增加,而且是呈指數級成長!

儘管大量的程式碼使得這種系統的編碼和除錯更加困難,但如果遵循一些核心原則,則可以省去大部份的除錯時間,例如:

  • 對即時性能、成本、可升級性、防護性、可靠性和安全性有影響的硬體/軟體進行分配
  • 實施容錯區域
  • 避免單點故障(圖2)
  • 處理由程式碼錯誤、程式本身、記憶體管理或虛擬中斷引起的異常
  • 將溢位檢查包括在內(Therac-25和Ariane火箭省略了這一程序)
  • 清理來自外界的污染資料(使用範圍檢查和CRC)
  • 在每一層級進行測試(單元測試、整合測試、系統測試、模糊處理、校驗和驗證等)

20171222_Barr_TA31P2 圖2:安全關鍵的系統(如車輛)避免單點故障 (來源:美國卡內基梅隆大學教授Phil Koopman)

冗餘加速器位置訊號(VPA1/VPA2) 安全架構不容單點故障 相同晶片上的VPA(與其它訊號)通過相同的輸入區塊 電子油門加速器 巡航控制 傳動變速桿 車輛速度 監測器ASIC 數位輸入& A/D轉換 故障點 其他感測器 監測器故障 運算節氣閥指令 節氣閥馬達&汽閥 電子燃油噴射與點火正時 引擎 VTA: 車輛油門位置 VPA: 電子油門加速器位置

為了安全起見,設計人員或開發人員必須熟悉使用者和裝置認證、公開金鑰基礎設施(PKI)和資料加密的複雜性。除了為授權使用者提供資產和保護資產免於未經授權的存取外,安全性還意味著系統在面對攻擊或故障時不會做出不安全或無法預料到的事。

當然,攻擊有各種形式,包括基本的阻斷服務(DoS)和分散式DoS(DDoS)。雖然開發人員無法控制系統受到什麼攻擊,但可以控制系統如何因應攻擊,而且如何因應攻擊的這種認知必須在全系統範圍內實施。系統最薄弱的環節決定了系統的整體安全程度,而假設攻擊者會發現該薄弱環節才是明智之舉。

針對薄弱環節的示例之一是韌體更新,可透過裝置的遠端韌體更新(RFU)特性實

以薄弱環節為目標的一個例子是韌體升級,其方式是透過裝置的「遠端韌體更新」(RFU)功能進行攻擊。此時的系統十分易於受到攻擊,所以最好是配備防範策略,例如:讓用戶選擇是停用RFU還是載入需要對後續影像進行數位簽核的更新。

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

在這些領域必須投入多少工作、時間和資源,取決於防護威脅的類型,每一種威脅都有具體的防範措施。開發人員可以採取如下一些常見舉措來提升產品的抗攻擊能力:

  • 使用無外部記憶體的微控制器
  • 停用JTAG介面
  • 實施安全啟動
  • 使用主要金鑰產生每個單位的裝置專用金鑰
  • 使用目標程式碼混淆
  • 實施上電自檢測(POST)和內建自測試(BIST)

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

確保安全與防護

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

採用像MISRA之類的編碼標準不僅有助於避免錯誤,還可以使程式碼更易閱讀、一致及可移植(圖3)。

20171222_Barr_TA31P3 圖3:採用MISRA等編碼標準不僅有助於規避錯誤,還可以使程式碼更易閱讀、一致且可移植(來源:Barr Group)

其次,使用靜態分析(圖4)。這涉及分析軟體而非執行程式。它是一種象徵性的執行,所以本質上是模擬。相形之下,在實際的程式碼執行於目標平台期間,動態分析將會發現缺陷。

20171222_Barr_TA31P4 圖4:靜態分析工具執行原始檔案的「模擬」、語法和邏輯分析,並輸出警示而非目標檔案(來源:Barr Group)

雖然靜態分析並非靈丹妙藥,但它確實增加了另一層保證,因為它能有效地檢測潛在的錯誤;例如使用未初始化的變數、可能的整數溢位/超過下陷,以及檢核和未簽核資料類型的混用。此外,靜態分析工具仍正不斷改善中。

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

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

第四,進行威脅建模。從使用攻擊樹開始。這要求開發人員像攻擊者一樣思考並執行以下行動: ‧ 確定攻擊目標:每次攻擊都有一棵單獨的樹 ‧ 對於每棵樹(目標):確定不同的攻擊;以及找出每次攻擊的步驟和選項

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

誰有時間把它做對?

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

例如,增加15%到50%的設計時間,以利於程式碼審查。一些系統需要完整的程式碼審查;有些則否。靜態分析工具可能需要數十到數百小時進行初始設置,但一旦進入開發過程的某一部份或階段,就無需額外時間進行產品開發了,他們最終都能透過更好的系統獲得回報。

連網技術讓嵌入式系統設計增加了新的顧慮,它需要特別著重於安全和防護性。對於這兩個概念的詳細瞭解、加上在設計週期之初就適當地應用最佳實務,能大幅提高產品的整體安全和防護性。這些最佳實務包括:採用編碼標準、使用靜態分析工具、程式碼審查以及威脅建模。

(參考原文:Designing for safety and security in a connected system,by Dan Smith、Andrew Girson,Barr Group)