物聯網終端應用TEE的一些思考

一.  引言

       近年來，可信執行的概念在物聯網安全領域也逐漸流傳。可信執行環境（TEE，Trusted Execution Environment）在智慧手機中的應用非常廣泛，如OP-TEE1、Trusty TEE等開源TEE。幾乎所有新上市的安卓手機都有TEE。那問題來了， TEE解決了什麼問題？整合在物聯網終端中否有必要？如果有，哪些能力能幫助終端或者物聯網提升安全等級？

       這些都是筆者初次聽說TEE這個概念的時候，腦子裡出現的一些問題，本文就講一講筆者對TEE應用在物聯網終端上的一些認識。

二.  名詞

2.1  認證

       一般我們說，認證透過後，才能建立可信的溝通。比如對面一個人說，他是你爸爸，但他蒙著臉，但你還是叫他爸爸，那是因為你聽他的聲音，看走路的動作，都能識別到他就是你爸爸，你透過他的聲音和動作做判斷的過程就是一個認證的過程。

      OpenSSL整合了許多加密演算法，依託密碼學來對通訊物件做認證，認證透過表示通訊物件是可信的。可信任程度則依據密碼安全程度、通訊場景來確定。一般，我們認為在物聯網應用場景中（除軍工外），RSA演算法的認證方式已經足夠強，該演算法也被整合到了SSL開源庫中，開發者可以根據自身產品需求整合一個合適的SSL庫，再基於SSL庫編寫好相應的認證程式即可。

2.2  OTP Fuse

       物聯網終端內整合了微控制器、微處理器、應用處理器等作為其運算、控制的核心。這些元件內部往往會有一個比較特別的儲存區域。一般儲存器提供給我們的基本功能就是讀取和寫入，但是這個區域中的儲存器，可以支援一次性寫入後不能第二次寫入，也就是說，儲存在這個區域裡面的資料不會被軟體更改。這就提供了一個可信任的基礎。因為更改該儲存區域的資訊是很難的，而且一個每個終端內，該區域的資訊是不同的，攻擊者攻擊了花費很大的時間、金錢來更改這個區域的資訊也很難獲得很大的利益，所以這個資訊在物聯網終端中是非常可信的。

       OTP全稱One-Time-Programmable，是由可以燒斷的一個保險絲控制讀寫邏輯的讀寫控制技術。我們暫時把這個儲存區域叫OTP區域。OTP區域內的資料可以被用來作為硬體唯一ID來用，在OP-TEE中對應HUK（Hardware Unique Key），基於HUK，可以衍生其他金鑰，比如SSK（secure storage key）、TSK（Trusted app Storage Key）、FEK（File Encryption Key）等。

2.3  Trust Application

       在一個終端上如果需要同時執行兩個作業系統，需要對時間和記憶體分片，分別將資源劃分給相應的作業系統，一般像Linux這種非安全作業系統，在OP-TEE裡面被稱為REE（Rich Execution Environment），與TEE對應。在REE中，如果想對比TEE中的資源，比如指紋，簽名，需要透過Secure Monitor這個“獨木橋”，如圖 1所示。有了這個獨木橋，即可對操作資訊、資料的合法性做校驗，如果不是授權的操作，則不允許訪問TEE的服務和資源。而TA則像是一個後臺服務，可以與合法的操作進行互動，代替REE訪問TEE內的敏感資源，比如把指紋資訊接收後，透過比對儲存在TEE中的指紋，驗證指紋合法性。

圖 1 OP-TEE設計結構

       與TA互動的應用程式被稱為CA（Client Application），比如支付寶，指紋登入等應用程式。CA儲存在REE（如Linux）中，具體互動流程網路上已經有相關專家分析4，這裡不再詳述。

三.  在物聯網終端內應用金鑰安全儲存

       一般，嵌入式Linux終端組成結構如下：

圖 2 嵌入式系統儲存結構

       Bootloader、Boot parameters、Kernel、Root filesystem這幾部分都儲存在終端的硬碟中，具體儲存結構如圖 2所示。從程式碼角度看，TEE更像是整合記憶體分割槽、讀取終端唯一ID、加解密庫、校驗等功能和機制於一體的程式碼塊，把這個程式碼塊移植到終端的哪個部分是沒有定論的，只要能保證程式碼可信即可。一般，在系統初始化完晶片的頻率、中斷、匯流排等以後，就可以使用TEE的程式碼引導後續的程式碼了。TEE相當於給bootloader加入了安全能力。如果我們把金鑰加密儲存在TEE的TA中，那麼金鑰也就在硬碟裡，防護有沒有效果，是和攻擊者逆向分析能力和對TEE系統的理解程度相關的。這也就決定了TEE只能在軟體上做安全儲存，無法實現硬體級別的安全儲存。在這種認識的前提下，我們怎麼基於TEE實現金鑰的安全儲存呢？

       此處，我們假設產品的各種除錯介面（JTAG、UART等）已經關閉，攻擊者無法連線到晶片上進行除錯，並以證書保護為例。一般，執行在REE側的應用，在連線網際網路時，如果考慮到通訊安全，會使用強認證來對雲端做認證，雲端為了認證客戶端的合法性，也要驗證客戶端的證書，所以證書、金鑰往往需要得到保護。在使用TEE時，有一個保護的思路，下面分享出來以拋磚引玉：

       使用TSK把REE中用到的金鑰加密以後放到TA中，使用時，CA向TA發起請求，獲取金鑰，TA把金鑰解密後，傳給CA，CA利用金鑰進行下階段的任務。

       然而，資訊就在終端內，只要能獲取終端，資訊已經在手，只不過獲取資訊途徑的難度不同。可以暫時分以下三類途徑：

1.    把硬碟整個複製出來；

2.    得到裝置執行時的root許可權，獲取CA執行時獲取到的解密的金鑰資訊；

3.    直接利用精密儀器把記憶體資料讀取出來。

       對於第一種攻擊，如果把裝置斷電後，拆開裝置，取出硬碟或者讀出flash晶片，金鑰就已經從終端內轉存到自己的電腦裡面了，我們怎麼找到它呢？得明確金鑰的位置：金鑰在TEE的TA中。

第一種攻擊實施成功，需要具備的能力如下：

1.    瞭解TEE啟動流程，知道TA中可能存在金鑰。

2.    具備很強的逆向分析能力，熟悉晶片結構。

3.    識別加密程式碼的加密演算法和加密模式，找到加密後的金鑰的密文。

4.    提取出加密金鑰和其他加密引數。解密金鑰密文。

       所以，如果攻擊者沒有具備齊全這四個能力，是無法獲取金鑰明文資訊的，資訊也就得到了保密。如果攻擊者實力強大，這四項能力都能具備，金鑰的安全也就無法保證。

       第二種攻擊中，獲取root的形式有兩種：一種是獲取終端自身的root許可權，另一種是透過qemu模擬啟動第一種攻擊中讀取到的硬碟檔案。我們假設終端沒有在硬體上暴露除錯介面，如果晶片的是BGA封裝，是沒辦法引出UART介面到另一臺PC機，進而獲取root許可權的。所以需要把硬碟檔案中檔案系統中的passwd檔案和shadow檔案做些調整，並開啟telnet服務，這樣，終端執行時候聯網即可透過網路訪問到telnet服務，並獲取root許可權。然而，在基於TEE的系統中實現這一套攻擊流程有一定難度，原因在於：從TEE的第一行程式碼開始，已經對後續的程式碼簽名。如果更改檔案系統，需要把整合在TEE裡面用來驗證程式碼合法性的公鑰更改，改完再用配套的私鑰簽名後，重新啟動才行。

        另一種是用qemu模擬整個系統。用qemu模擬系統是可行的，但是也很有難度。難度之一是TEE本身需要讀取到OTP區域的ID作為根金鑰。必須要編寫一個可以和TEE系統互動的程式配合TEE完成OTP區域的讀寫過程，才能進入後續階段2。難度之二是這個互動的過程需要逆向分析TEE的程式碼後才能找到。如果這兩步驟完成，系統外設可以正常模擬，那麼root許可權的shell也就可見了。

       獲取到root後，啟動CA，金鑰會被CA讀取到記憶體中，這時只要採集記憶體資訊即可讀取到金鑰的明文資訊。

       第三種攻擊是可行的，直接讀取記憶體資料，可以用一個可以高速採集的邏輯分析儀讀取匯流排上的資料。然而這種難度只會比前兩個更大，一來，這種精密一起比較昂貴。二來，讀取出來的資料也要變成可讀的，這對攻擊者的記憶體讀寫技術方面的知識積累要求很高。攻擊者必須瞭解什麼時候匯流排訊號在傳輸地址訊號，什麼時候匯流排訊號在傳輸資料，還要分離出金鑰的明文。

四.  總結

       由上可知，在物聯網終端上應用安全儲存，實際上並不能真正的實現100%的不可讀，但是卻能提高逆向分析終端的難度。而實際上，隨著智慧手機應用TEE技術，終端自身的安全問題的確少了許多，但是隨著攻擊者攻擊手段和知識水平的提高，僅僅用TEE做安全儲存並不是長久之計。還需要結合比如NXP的Kinetis Security and Flash Protection Features5，或者ST公司的RDP6的思路，把金鑰寫入到一個真正只有拆解晶片來拍照逆向才能讀取的一塊區域中，這樣才能達到晶片級別的防護。而物聯網環境下，達到晶片級別的防護，其破解成本已經足夠強，而且能很好的應對前兩種攻擊手段，因為金鑰並不在外部的flash中，在開啟讀保護的前提下，攻擊者只能讀記憶體或者拆晶片來獲取金鑰。而廠家只需要保證自身產品的升級流程是安全的即可，因為升級過程可以重新刷寫晶片內部flash區域，如果攻擊者利用了升級漏洞，會把讀保護標誌位置為可讀。

       TEE是可信執行環境，在應對敏感資料持久化儲存方面儘管不是目前最好的解決辦法，但是自身的安全機制已經提高了破解條件。結合其他技術，物聯網終端一定可以比較完美地保護起來。

       其他因為TEE機制導致的效能損失，可以經過測試後7，根據自身產品現狀決定需不需要採用TEE這樣一套機制，或者決定需不需要最佳化TEE的效能。

       筆者接觸TEE的時間比較短，如果文章中有些描述或者思路有些錯誤、不成熟、或者不合理的，希望讀者能向作者提出，歡迎指正。

參考連結

1.    OP-TEE官方文件，https://buildmedia.readthedocs.org/media/pdf/optee/latest/optee.pdf

2.    Emulating Exynos 4210 BootROM in QEMU，https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html

3.    構建嵌入式Linux系統，https://goooooouwa.github.io/coding/2012/10/30/%E6%9E%84%E5%BB%BA%E5%B5%8C%E5%85%A5%E5%BC%8FLinux%E7%B3%BB%E7%BB%9F.html

4.    TEE 軟體互動流程概述，http://kernel.meizu.com/tee.html

5.    Using the Kinetis Security and Flash Protection Features，https://www.nxp.com/docs/en/application-note/AN4507.pdf

6.    Proprietary Code Read Out Protection on STM32L1 microcontrollers，https://www.st.com/content/ccc/resource/technical/document/application_note/b4/14/62/81/18/57/48/05/DM00075930.pdf/files/DM00075930.pdf/jcr:content/translations/en.DM00075930.pdf

7.    Developing Secure Services for IoT with OP-TEE A First Look at Performance and Usability，https://www.researchgate.net/publication/332726463_Developing_Secure_Services_for_IoT_with_OP-TEE_A_First_Look_at_Performance_and_Usability