工研院資通所 王子夏、陳立函、趙翊廷、劉哲豪、黃莉婷
應用程式白名單是無聲的守護者，讓惡意程式無法攻擊，具強大資安保護功能。白名單技術簡介
應用程式白名單（Application Whitelisting）只允許已知的合法應用程式在系統上執行，適用在固定功能的電腦設備。例如車載系統、或自動化工廠機台。過去普遍用黑名單技術進行資安保護，由於惡意軟體（Malware）數目快速增加，已使得黑名單防不勝防，於是反過來利用白名單阻止未知程式執行，相較之下，白名單限制範圍更大，它確保系統中受信任的軟體才能執行，即使惡意程式在周圍環伺也無法作怪。
惡意程式慣用的入侵手法是利用軟體弱點進行攻擊，如在電子郵件中提供連結，點擊執行後塞一小段程式碼（Shell Code）進來，再透過這個小程式植入惡意軟體伺機執行，一旦開了此門就有如邀請壞人住家裡，隨時財產受威脅。惡意程式可在下載時啟動偵測或在源頭處把關即在入口處攔下，或者執行軟體弱點掃描也可避免漏洞發生。但就算有千百種防禦手法仍然難免疏漏，更不要說惡意軟體也時時翻新，天羅地網仍無法全面抵擋入侵。應用程式白名單的存在就是最終防線，無論惡意程式經由什麼媒介、什麼手段侵入，在它被啟動時即遭系統阻擋，使惡意攻擊無法得逞。惡意軟體有如偷渡客，白名單就是檢查哨，安全清單則是過關的基準，讓合法軟體照常執行又提防到惡意攻擊，是白名單機制的主要目標。
自駕車資安防禦受重視 大廠緊抓機會
著名分析諮詢公司IHS Markit預測，至2025年為止全球自駕車銷售量將會達到60萬輛以上，而2035年將會達到2100萬輛之譜[5]，隨著各家大廠積極搶入自駕技術研發，無人車離行駛於道路上僅剩最後一哩路。而當我們持續嘗試移除車輛中的方向盤、油門與煞車等物件時，首先必須確保車輛在自動駕駛時能夠同時保護車內乘客以及道路行人的安全，現階段眾家廠商的研究資源都集中於車輛的行駛安全，對於車用資通訊平台的資訊軟體防護部分尚未成熟，但伴隨著過去以機械為主的汽車導入了更多的電子設備，民眾對於車載平台上資訊安全的要求也將會大幅增加。曾經與智慧行動終端市場失之交臂的BlackBerry此次並未忽視車載技術的熱潮，於2016年底建置自駕車研究中心並大量投入研究資源，BlackBerry所擁有的QNX平台目前在車用市場中擁有47%的市占率，且將於2018年推出自駕車用的資安服務平台[6]，該平台預期將可遠端掃描檢測車用軟體是否感染病毒或遭受入侵，並且若在行駛當中發現車載平台異常可能危及行車安全時警告駕駛停車，而QNX更是目前少數符合汽車電子系統安全國際標準（ISO-26262）的作業系統，QNX在資訊安全方面的領先也將成為了BlackBerry未來重返舞台的關鍵優勢，同時彰顯了資安防禦技術於車載平台上的重要性。
鑒於目前惡意攻擊的盛行，可想而知擁有龐大未來市場以及配備高運算資源的自駕車輛必然是下一個攻擊溫床，車輛上運行的所有電子系統都有可能成為資安攻擊（如圖1所示）的目標或是攻擊媒介，試想近年掀起軒然大波的勒索軟體（Ransomware）發作於車載平台的畫面，原先大幅肆虐於網路上的攻擊轉移至道路上時只會造成更加嚴峻的災情。
圖 1 車載資通訊平台惡意攻擊類型車載資安廠商多採用白名單類型技術
研究分析諸多車載資安相關之解決方案（如圖2所示），有71%廠商在產品或是技術發想上採用白名單（Whitelisting）類型的技術，採用方式可分為三大類：
(1)在ECU上利用原廠設定建置白名單，不符合原廠設定之程序無法於ECU上執行
(2)建置control-flow白名單，程式控制流程異常時則中止操作
(3)透過機器學習認知駕駛習慣，當操作與駕駛習慣差異太大時則產生警示 6%產品強調利用Hypervisor機制隔離車輛中的重要執行區塊，避免惡意程序透過特權提升取得管理者權限。59%廠商在產品上採用軟體解決方案，41%廠商採用硬體方案，裝置額外硬體需透過與車廠的技術整合，技術成本較高。使用軟體安裝方式較為便捷，但若是直接嵌入於ECU上時，容易因為占用ECU資源而造成ECU執行效能受影響的狀況。41%廠商在產品上自行建置或是透過其他資安廠商的雲端服務，任何通訊或是檔案的下載都會在雲端系統先經過檢測，當檔案安全時才會再從雲端下載至車輛，並且雲端系統會不斷更新目前新發現的惡意檔案或是攻擊行為特徵，此方式可保持防禦機制永遠處於最新更新的狀態。29%廠商在產品或是技術發想上採用機器學習或是人工智能技術，採用方式多利用機器學習方式分析新型攻擊或是惡意程式特徵，進而產生偵測規則置入防禦偵測系統中。24%廠商在產品或是技術發想上採用金鑰技術，透過公開金鑰簽章與身分驗証確認通訊的對象是可信賴的裝置，各端點間傳輸也可透過金鑰加密，確保機敏資料不會外洩以及傳輸的完整性。其中多數公司為以色列新創公司，以色列政府因為軍政地理關係對於資安產業非常重視，持續以國防需求帶動資安產能，近年車載資安廠商的興起可觀察出其政府對於此領域的重視，因此對於政治與環境關係相對類似的台灣而言，發展車用資安防護技術以確保系統運行的安全性將是一個近期需加速發展的議題。
圖 2 車載資安廠商解決方案類型統計圖另外本段分享來自日本對於車載平台的相關資安訊息，首先由日本車商主導的Automotive Grade Linux (AGL)專案是Linux基金會的專案項目之一，此開源專案主要的背後主要貢獻者為日本五大車商包含：豐田、本田、鈴木、馬自達及速霸陸，另外也包含日本大廠瑞薩、富士通、國際牌與日本電氣。身為目前全世界最大的車載開源作業系統平台，日本廠商在商業上彼此有高度的合作，從硬體研發到軟體系統皆以日系為其主流的色彩濃厚。
本次選擇參加此會議的目的為了解日本車廠對於自駕車發展的技術現況，並從其中去探討關於車載資訊安全方面，該社群對於此議題的想法。以利我們未來對於車載資安方面能夠有更好的修正和規劃，增強我國資安產業競爭力。會議中可發現針對半年多前的CPU bug對開發者是很挑戰的一年，都有很大的壓力要盡快的做出修補，且不影響系統運作的正確性，因此社群的貢獻者們花了很多的精力去做好測試。而往後的日子裡，依然得不斷的持續進行修補，也要請使用者跟上更新的腳步，避免被惡意的使用者破壞。
而由於AGL還算是滿新的專案，參與的廠商也很多，因此會議上首重的是如何做好持續整合，而在進行持續整合的過程，必須要做到：不斷的增加測試條件、程式碼靜態分析以及系統效能分析。這些過程因為牽扯到硬體開發板的關係，故整個測試生態就不只是傳統的Jenkins能夠使用，還需要用到Fuego與LAVA等專案才能夠做好相關測試與持續整合，更可貴的是整個測試結果以後還能夠整合到後端平台，顯示出整個專案現階段的測試結果。這個部分非常值得各軟體開發團隊借鏡。
圖 3 TOYOTA 展示AGL平台於實體汽車上人命關天 資安防禦技術須符合自駕車規格
目前發展中的新世代車載產品皆強調高智能與連網能力，但這些條件也等同於為惡意程式布建了執行環境與攻擊缺口，如果被攻擊的產品為一般智能家電，可能只是導致電力耗損或是使用資料洩漏，但是當受攻擊對象為自駕車輛時，將會引起嚴重的交通事故。另一方面，目前現行車載平台多為車用資訊娛樂系統，無法進行V2V （Vehicle-to-Vehicle）通訊，但未來將進入車聯網V2X第三代技術，將進入包含V2V、V2P（Vehicle-to-Pedestrian）、V2I（Vehicle-to-Infrastructure）與V2R （Vehicle-to-Roadside）等關鍵技術的時代，自駕車輛將在不久的將來完全進入物聯網的範疇中，只要掛載的車載平台缺乏足夠防禦能量，在「萬物聯網，萬物皆可駭」的概念下，一個指令就可以脅持車輛的煞車與引擎[7]，自駕車將成為攻擊者手中最具威脅性的籌碼。為解決此嚴重的安全隱憂，工研院提出的資安強化車載平台，囊括兩大資安技術：（一）輕量虛擬化（二）應用程式白名單，透過輕量化布建，在不影響原先車載系統運行效能的前提下，針對未經紀錄之可疑程式予以拒絕執行，避免惡意程式控制車輛。
資安強化車載平台利用虛擬化技術來檢查虛擬機內執行的程式是否在白名單當中，而一般認為在虛擬化環境下執行會有一定的效能負擔，因此在輕量化虛擬機部分需要輕量虛擬化的幫助，透過輕量化虛擬機層級之I/O效能提升，在使用虛擬化技術時也提供高效的硬體使用率，目前在ARM環境下已與國內數家廠商討論合作，並在開發平台上進行系統核心與虛擬機層級的實作研究。另外，於應用程式白名單的部份，如圖3所示，主要透過記憶體為基礎的白名單技術進行更嚴格的程序管控，每個記憶體頁面（memory page）要執行的時候都檢查此頁面是否在白名單當中，避免保護名單外的可疑程序在平台內執行，相關技術研究在國際上已有20餘年的歷史，但綜觀相關產品，目前大多無法有效針對所有可執行程式類型進行有效阻擋，而且更需符合車規標準。
圖 4 應用程式白名單程序控管基於上述特點，所提出之資安強化車載執行平台可達到：（一）發展國內車載資訊安全核心技術（二）連結自駕上下游廠商發展產業合作（三）搶先布局國內外車規等級資安專利技術。
資安強化車載執行平台將大幅提升產業界在車載系統資訊安全的技術層次與防護能量，發展符合ISO-26262、SAE-J3061與SAE-J2735等車規標準之車載安全執行平台，避免自駕車輛上之重要資訊被竊取甚至系統遭到滲透、入侵或癱瘓，並且將可配合產業界的實際需求，提供多載體的輕量化設計，在資安防護的同時維持原先系統的運算效能。產業合作方面由於政府將資安產業納入國防產業發展的一環，支持產業研發能量投入，且國內車輛相關廠商擁有車載硬體模組生產經驗，將從上游晶片平台導入並擴散至下游系統廠，合作布局車用等級軟硬體技術市場，提供國內廠商未來更寬闊的發展空間。
資安防禦能力之車載平台 實現Level-5關鍵防禦核心技術
具備資安防禦能力之車載平台是實現自駕技術完全自動化（SAE Level-5）中最為關鍵的防禦核心技術，所提出之車規資安技術在未來自駕車市場逐漸成熟後，將可解決自駕車遭受機敏資料竊取、惡意程式入侵等攻擊，也可進一步協助處理車輛失竊等議題。目前全球科技大廠仍處於百家爭鳴各自研發的階段，於此時投入發展將可與各家車廠站在相同的起跑點上，我國將有機會於未來車載平台資安研究領域位於領先地位。而市場上現階段對於平台的需求多以軟體運算層面為主，目前車用軟體與其運算平台尚處於開發初期，安全方面也相對較重視車輛的行駛安全，對於軟體驗證與平台資安的防護尚未成熟，因此預期將針對車載平台其輕量化、程序驗證、資安防護等演算法與防禦技術提出專利申請，在車規資安防護部分尚未受到普遍重視前，著手研發及布局關鍵專利，未來並將積極與國內車載平台以及Tier-1/2車廠供應鏈廠商共同制定規格，將可於全球車載業界中建置一完整的專利保護網。國內車廠技術品質達國際水準，皆通過歐美地區售服零組件等相關認證，並且擁有完整國際行銷通路，但關鍵技術仍仰賴國外，若透過車載平台專利布局掌握自駕車關鍵技術，將可協助國內車廠在未來居於發展自駕車輛的領先地位。
白名單技術應用於視窗系統的實行作法
白名單基本邏輯簡單，它並不偵測程式惡意與否，它只區分認識不認識。為此，程式須有唯一識別碼來代表它的身分，以程式資料計算而出，猶如隨身攜帶了指紋，即使惡意程式改了名、搬了家也能認出來並在合適時機加以過濾。所以啟動白名單保護前先建立安全清單，此清單是合法程式的集合，必然是清清白白在系統運行已久。其次要有機制監控應用程式的執行。在視窗作業系統下可藉由篩選性驅動程式架構（Minifilter Driver Architecture）來達成，其構成如圖5，此架構允許攔截可執行檔（Executable）操作，也可改變操作結果。先要分辨何種執行方式會帶來危害，惡意程式潛伏於系統，終究要建立行程才能展開活動，此時就是最佳檢查點，若為已知程式就放行，反之拒絕。更嚴謹一點，即使是安全已知的程式，其引入的外部程式仍然可能造成危害，更要顧慮不明系統檔（通常是驅動程式）的破壞力，由於它可在核心模式下運行，對系統具有更大威脅。白名單機制在每一道程式建立行程及載入外部程式時，計算出唯一識別碼，比對資料庫後決定執行與否。無論何種形式，在所有啟用程式的時機進行攔檢，才不讓惡意程式有機可乘。
圖 5 視窗系統的篩選性驅動程式架構視窗系統防護-對腳本攻擊的防範
原先腳本程式（Script）用於簡單任務自動化，近年來為了方便人員管理系統而增加了種種支援，如今已無所不能，其作用幾乎等同Program，何況還免編譯。以視窗作業系統來說，最常見的是Cmd Script和Powershell Script，基本可以取得系統中資料，超過能力的部分，甚至可叫用其它軟體來達成。腳本程式如此便利，不免也受到駭客的窺視，它比Shell Code作法更容易。入侵的典型範例是利用腳本檔，讀取記憶體或註冊表（Registry）內容重排成指令，暗中連到遠端網站下載惡意程式後執行，然後就災難了。一些資安解決方案已成腳本攻擊防禦的較量，腳本程式能逃過檢查，主要因為它是文字檔需由直譯器（Interpreter）帶動執行，直譯器通常也是合法程式，照理要執行，問題在於，直譯器本身無害，輸入參數卻可能是惡意。按白名單概念，執行檔有分可信和不可信，腳本程式也可比照，當直譯器啟動時攔截下來，解析它的輸入腳本，若在安全清單中，才會允許直譯器工作以杜絕惡意程式碼。但世上腳本類型這麼多，防得了一個防不了所有，此時須有聰明機制，找到直譯器指令的共同性，並建立以規則為基礎（Rule-Based）的解析功能，對於所關心、有擔憂的腳本程式，令它加入規則，而不是增加程式邏輯。同一偵測演算法應變各種直譯器，如此作法容易擴充腳本支援，確保白名單防守動作比入侵攻擊快。
視窗系統防護-對DLL Injection的防範
對於某些病毒而言，有一種技巧是將惡意程式碼包在動態連結程式庫（DLL，Dynamic-Link Library）中。其主要是利用視窗系統API的特殊性，把程式庫路徑名稱寫入到一記憶體空間，再啟動執行緒運行在某行程，利用載入程式庫的機會將惡意程式注入到程序裡執行。對此，白名單的防禦應對是將動態連結程式庫也視同執行檔，在它將被載入的當下攔截檢查，前面的曲折不必理會，由駭客去折騰，無論惡意程式庫怎麼進來，只要緊盯載入的時機即可阻斷它執行。
視窗系統防護-設計挑戰
白名單的加入不是為了改變系統，而是讓良好的系統不被改變，構想很保守但安全。多做檢查意味著多付出成本，首先效能就會受衝擊，因頻繁查問可能導致執行不順，體質較差的系統甚至引起過載。據觀察固定功能的設備它的程式也非常固定，主要分兩類：一是核心程式負責調用資源、排程、檢查權限……等，二是應用型程式真正擔負起系統功能。實驗結果核心程式經常重複執行，「大量而重複」正是快取（Cache）發揮的時候，以程式識別碼為索引，第一次執行實際連資料庫做查詢，第二次以後快速核對記憶體資料，當快取起作用之後已不感覺有白名單攔查。除此還有穩定度的考量，不影響系統運作是基本要求，使用作業系統原生的攔截架構已做對一半，其餘要考慮程式除去複雜化並減少倚賴外部資源，否則執行期增加拖累造成不穩定。程式簡單為上，卻不應犧牲功能性，最好的安排是關鍵檢查即時消化，非緊迫功能則丟到背景處理，例如寫日誌、管理操作... ...等，架構正確了才不致干擾主要工作。更困難的挑戰是人為破壞，白名單要保護系統也要保護它自己，保護重點無非程式和資料。有心人士會試圖終止白名單行程，之後便能為所欲為，監控程式須警覺這個危險動作而防止它執行，若人有意刪除竄改資料庫，方法是鎖住檔案並阻擋不相關行程操作資料，以白名單行程代碼或本身的程式識別碼即可提供判斷。可知打造一個穩定又打不死的軟體要經過重重考驗，但必須如此，駭客招數太多，白名單以一擋千，唯有強大自己才能幫助到系統安全。
視窗系統防護-營運上的難題
分析收集應用程式安全清單往往要花費不少時間，造成營運佈署耗時過久，單個設備花費一點點，若到一定的數量例如產線主機，總體就不只花費一點點，一般也無法忍受系統停擺太久，對於相似系統，可藉內定清單減少安裝佈署的等待時間。應用程式安全清單可事先從乾淨的系統收集而來，乾淨的系統譬如剛裝完、沒有不明軟體、且正常運作一段時間，掃出來的結果適用在相似系統，如此在大量佈署時只須複製第一台的結果。再則當軟體自動升級時，須有一機制將更新後的執行檔加入資料庫，否則白名單沒有新資料，此軟體將無法正常執行。要能分辨是否為正常更新或是惡意程式在作用，兩者都製造檔案且少有特徵可供區別，土法煉鋼作法是觀察每一款應用軟體每一版本的更新結果，符合這些結果就接受，更智能的作法是以機器代替人工觀察，並且檢驗更新程式的來源，如此雙管齊下更確保清單不被惡意程式汙染。另一個難題是白名單保護太過，以至於管理員什麼都不能做、什麼都被阻擋，沒錯白名單機制不適合經常變動的系統，它使人員操作非常不方便，但總有需要手動維修系統的時候。顧慮到人員進場通常就是資訊安全最大缺口，為了防堵又要滿足維修需求，是故設計一個維修模式，以非常嚴格的認證方式確認管理者身分，避免被任意侵入改動設定，它提供特殊權限允許有限作業，期間系統還是受白名單保護，提防到如此地步，減少因人員失誤帶來的安全威脅。
應用程式白名單-無聲的守護者
國際上已將強化資安環境列為重要發展目標，對於資安危害與其收拾善後不如事前預防，就如同健身，平時看不到成果，但是它可減少病痛發生以及復原所需的代價，所以不得不看重。白名單的地位更接近於系統程式，未來不著重追求多使用者功能，應以穩定性、多防禦支援為主要，做到平穩快速不佔資源，像無聲的守衛者，系統中有白名單又好似沒有白名單，就是它的最佳境界。
