論文閱讀（三）

 

所有論文筆記請戳：http://blog.csdn.net/lwyeluo/article/details/54017718

 

 

1. SGX

SGXIntel開發的新的處理器技術，可以在計算平臺上提供一個可信的空間，保障用戶關鍵代碼和數據的機密性和完整性，從SGX提出後，其吸引了一批系統和網絡安全的研究者，NCCGroupSGX方面的資料進行了一個初步的總結，對研究者學習SGX技術具有很好的引導作用。這裏主要根據該博文對SGX進行簡單的整理。

目前並沒有基於SGX的產品出現，不過學術界已經給出了一些應用來說明SGX的強大，相信工業界也正在開發對應的產品。SGX能將安全應用依賴的可信計算基TCB減小到僅包含CPU和安全應用本身，將不可信的複雜OS和虛擬機監控器VMM排除在安全邊界之外。

 

SGX Intel Software Guard Extensions，顧名思義，其是對因特爾體系（IA）的一個擴展，用於增強軟件的安全性。這種方式並不是識別和隔離平臺上的所有惡意軟件，而是將合法軟件的安全操作封裝在一個enclave中，保護其不受惡意軟件的攻擊，特權或者非特權的軟件都無法訪問enclave，也就是說，一旦軟件和數據位於enclave中，即便操作系統或者和VMM Hypervisor）也無法影響enclave裏面的代碼和數據。Enclave的安全邊界只包含CPU和它自身。SGX enclave也可以理解爲一個可信執行環境TEE Trusted Execution Environment）。不過其與ARM TrustZone TZ）還是有一點小區別的，TZCPU劃分爲兩個隔離環境（安全世界和正常世界），兩者之間通過SMC指令通信；而SGXCPU可以運行多個安全enclaves，併發執行亦可。當然，在TZ的安全世界內部實現多個相互隔離的安全服務亦可達到同樣的效果。

 

相關文獻資料

---Intel發佈了三個博客給出了SGX的設計目標（總共8個設計目標），作爲理解SGX的背景材料比較重要：

1Intel? SGX for Dummies (Intel? SGX Design Objectives) : September 2013, Matthew Hoekstra

2Intel? SGX for Dummies – Part 2 : June 2014, Matthew Hoekstra

3Intel? SGX for Dummies – Part 3 : September 2014, Matthew Hoekstra

 

SGX是一系列的系統指令，爲應用程序留出數據與代碼的私有區域。動機有以下八點：

1. 允許應用程序開發者保護程序的敏感程序，避免被非授權的訪問，或者被運行在更高層的特權惡意軟件修改。
2. 在不破壞合法系統軟件來調度與管理平臺資源的前提下，允許應用程序來保護敏感代碼與數據的機密性與完整性。
3. 允許計算設備的用戶保持對平臺的控制，支持自由安裝與卸載應用程序及服務。
4. 允許平臺來度量一個應用程序的可信代碼，生成處理器對應的簽名證實報告，這個報告包含度量值與其他證明該程序在一個可信環境中初始化的證書。
5. 允許使用常見的工具與處理器來開發可信應用程序。
6. 允許根據應用程序處理器的能力來據丁可信應用程序的性能。
7. 允許軟件開發商使用自己選擇的分發通道，來分發或者更新應用程序。
8. 允許應用程序定義代碼與數據的安全區域，即使在攻擊者能夠物理控制平臺或者內存攻擊的情況下，依舊能夠維護機密性。

 

---SGX本身的運行機制可以通過如下資料瞭解（前三篇是Intel2013HASP workshop上一連出三篇介紹SGX的文章）：

4Innovative Instructions and Software Model for Isolated Execution: June 2013, Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos Rozas, Hisham Shafi, Vedvyas Shanbhogue and Uday Savagaonkar, Intel Corporation

5Using Innovative Instructions to Create Trustworthy Software Solutions

6Innovative Technology for CPU Based Attestation and Sealing

7Intel? Software Guard Extensions(Intel? SGX) Instructions and Programming Model: June 2013, Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos Rozas, Vedvyas Shanbhogue and Uday Savagaonkar, Intel Corporation

8Intel? Software Guard Extensions(Intel? SGX): November 2013, Carlos Rozas, Intel Labs (given at CMU)

9Intel? Software Guard Extensions Programming Reference Rev 2 (#329298-002): October 2014

---Technische Universit?t Darmstadt (CASED)Ahmad-Reza Sadeghi作了一個關於嵌入式系統安全的講座，其中對Intel SGX這塊也有一個報告，總結的很不錯，如下：

10Trusted Execution Environments Intel SGX

 

---SGX的基本運行方式和原理後，用戶最關心的就是SGX能有什麼實際應用了，大家都知道PC"WinTel"時代，也就是微軟和因特爾密不可分的關係，最先實用SGX的就是微軟了，值得關注的是微軟的VC3Haven，文章分佈參考如下鏈接：

11VC3: Trustworthy Data Analytics in the CloudOctober 2014

12Shielding applications from an untrusted cloud with Haven OSDI 2014

 

---作爲安全方向的新技術，由於還沒有實用的系統和產品，分析其安全性就是比較重要的一步，下面資料是關於SGX技術的一些安全分析：

13Intel Software Guard Extensions (SGX) Is Mighty Interesting: July 2013, Rich Mogull - Discusses the positive applications against malware, hypervisors and potential to replace HSMs.

14Thoughts on Intel's upcoming Software Guard Extensions (Part 1): August 2013, Joanna Rutkowska – Initial high-level thoughts on the functionality provided and how it compliments existing Intel technologies.

15Thoughts on Intel's upcoming Software Guard Extensions (Part 2): September 2013, Joanna Rutkowska – Lower-level thoughts on good and bad applications for SGX.

16SGX: the good, the bad and the downright ugly: January 2014, Shaun Davenport & Richard Ford -

 

SGX的模擬器與CPU

 

SGX技術有一定理解後，會忍不住想要親自試試該技術，不過目前好像還沒有支持SGXCPU出現，而且模擬器也很難找到。不過，模擬器是肯定存在的，不然微軟也無法評估VC3Haven的原型實現了。從Intel發佈的文獻以及VC3Haven的論文中，可以發現，IntelSGX模擬器，並提供給了微軟，而微軟嫌性能不夠，自己也開發了一套軟件SGX模擬器（不過提供的安全保障不強）。因此，想要嘗試SGX的模擬器，與Intel和微軟聯繫，要到模擬器是不錯的選擇。

 

Georgia Institute of Technology也有一個項目，是用QEMUSGX，可以參考Intel SGX Emulation using QEMU

 

至於目前市場上是否存在支持SGXSGX2CPU，答案也比較明顯，暫時沒有。

 

[1] Intel? Software Guard Extensions (SGX): A Researcher's Primer.https://www.nccgroup.trust/en/blog/2015/01/intel-software-guard-extensions-sgx-a-researchers-primer/

 

1. The Protection of Information in Computer Systems

   1. 摘要

本文介紹了保護計算機信息不被未授權使用或者修改的機制，更注重於敘述支持信息保護相關的所必要的結構（軟硬件）。本文分三部分進行描述，第一部分是目標功能、設計原則、基本保護與認證機制的實例；第二部分熟悉基於描述符的計算機架構，深入說明現代保護架構的原則、能力系統與訪問控制列表系統之間的關係、對保護子系統與保護客體的一個簡要分析。第三部分回顧之前的工作、現在的研究進展，併爲將來工作給出建議。

1. 信息保護的基本原則

   1. 保護研究的思考

      1. 普遍觀察

對於所有用戶不應該擁有同一的權利的應用，必須要有一些機制能夠確保計算機系統實現了預期的授權結構。

公司社團信息保護示例：對於航空座位預訂系統，一個預訂代理被授權來接受與取消預訂，登機代理被授權來給出乘客預訂信息，航空公司可能不希望預訂代理來給出預訂列表，而是從一個法律機構來拿到。

網上倉庫存貨管理系統：生成存貨信息報告，報告包括公司信息，與工作（存貨）質量等。需要保護不被公司外部獲知，隱私保護（授權訪問）。

Privacy與security：Privacy爲私人數據能夠在什麼時候、地點分發給誰；security爲控制想要修改、使用計算機或者信息的用戶或其他人。

三種類型的安全問題：

1. 未授權信息發佈
2. 未授權信息修改
3. 未授權使用拒絕

針對這些安全問題的一些安全技術做法：

1. 給文件打上標籤，描述授權的用戶（保護）
2. 通過口令等方式驗證用戶身份（認證）
3. 防護計算機避免電磁輻射竊聽
4. 信息加密
5. 爲有這臺計算機的房子上鎖
6. 控制誰能修改計算機系統
7. 使用一些冗餘的電路、反覆覈對來維護安全
8. 證明軟硬件符合預期

   1. 信息保護的功能層次

根據功能屬性對這些安全保護機制進行分類：

1. 未受保護的系統：
2. all-or-nothing system：提供用戶之間的隔離，有時允許共享信息
3. 受控共享：明確控制誰能訪問系統上存儲的每個數據項，可能提供授權用戶訪問列表，控制讀寫執行等操作。
4. user-programmed共享控制：標準機制裏沒有提供的訪問約束，如在某個時間點能夠訪問某個數據項，兩個用戶同意後才能修改某數據。這種情況下，應該提供一個用戶定義的受保護客體與子系統。保護子系統是一些程序、數據的集合，要求只有子系統的程序才能直接訪問這些程序或數據。
5. 往信息中put字符串：前面三個是分發信息的條件，當前這點是信息分發之後的控制，如輸出的數據打上某些安全級別標籤

   1. 設計原則

保護機制的八個設計原則示例：

1. 成本：儘可能簡單、小巧。
2. 保守設置（Fail-safe defaults）：訪問控制決策是允許什麼操作，而不是排除什麼操作。即默認是不允許的。
3. 完全仲裁（Complete mediation）：對任何客體的任何訪問都應該仲裁。
4. 開放設計（Open design）：被更多的人review，而增強安全
5. 特權分離：兩個密鑰才能解鎖的保護機制比一個要好
6. 最小特權：使用最少的必要的特權來完成任務
7. 最少公共機制（Least common）：Minimize the amount of mechanism common to more than one user and depended on by all users.每一個公共的機制增加用戶之間信息傳遞的潛在風險
8. 心理上可接受

傳統的物理安全系統還暗示着應引入另外兩種原則：

1. 工作因素（work factor）：對於攻擊者來說，迴避這些機制的成本與可獲取資源的價值對比
2. 折衷記錄（Compromise recording）：一個信息被破壞的可靠的記錄，能夠被更復雜的安全機制來利用

1. 技術支持

   1. 開發計劃

   2. 信息保護概要

   3. 虛擬機隔離

一種使得虛擬機進行隔離的機制是描述符寄存器（descriptor register，DR），如下圖。DR控制內存的哪些部分能夠被訪問，包括兩個部分：base、bound。DR中的值爲描述子（descriptor）。爲保護描述子，控制誰能夠使用描述子，最常見的做法是在處理器中增加一個特權位（privileged state bit），只有在該位爲ON時才能改變描述子。圖1中的S爲supervisor，擁有這個特權。Supervisor程序維護一個描述子的表，每個是一個虛擬的處理器。

這樣，虛擬處理器的實現有三層保護機制：

1. 不同程序不同信息：描述子確保其安全
2. 描述符寄存器：特權位確保其安全
3. 特權位：supervisor程序就是一個保護子系統

1. 認證機制

認證機制與保護機制不同，請求方是用戶而不是程序，所以不能物理控制。最常見的做法是用戶口令。

口令的缺點：

1. 知道用戶習慣的很容易猜中口令，系統生成隨機數當作口令很難記憶
2. 遠程使用時，口令必須經過傳遞（故藉助加解密系統）

所以很多系統使用不可僞造的物體來代替口令。

口令與不可僞造物體方法存在同樣的問題：機器認證用戶，用戶沒有認證機器。

1. 信息共享

信息共享保護機制的兩類實現：

1. List-oriented：用戶有唯一標識，信息（客體）維護授權用戶列表。
2. Ticket-oriented：信息有唯一標識，用戶有不可僞造的標識集合，每一個代表能夠訪問某個信息。

List-oriented要求客體遍歷掃描，Ticket-oriented爲用戶訪問前掃描，在應用程序擁堵情況下，後者更好。一個客體維護的表size爲1，或者對應的ticket只有一個，就是完全隔離。

藉助VM隔離的機制，可以通過兩個描述子來共享信息，如圖2所示。這樣需要注意：

1. 如果虛擬處理器P1能夠覆蓋共享的數學程序，這可能影響虛擬處理器P2正常工作。

   解決方案：爲描述子增加讀寫位，控制讀寫權限

2. 共享數學程序修改自身代碼時要注意臨時結果在內存中的位置，因爲有可能同時獨立執行。
3. 應該能夠擴展到有多個共享程序。

   解決方案：能力系統（ticket-oriented）與ACL系統（list-oriented）

4. supervisor能夠知道哪些能夠使用共享程序。

1. 基於描述子的保護系統

   1. 地址與保護分離

段（Segment）：用來給內存地址區域提供唯一標識。每個段有一個不同的地址描述子（addressing descriptor），如圖5所示。內存系統的所有用戶都有相同的地址描述子，段描述子（保護描述子）有特權位用來決定用戶特權。

1. 能力系統

如下圖所示，假定每個處理器有4個保護描述子，A控制處理器，省略地址描述子。

1. Sego: Pervasive Trusted Metadata for Efficiently Verified Untrusted System Services

   1. 摘要

Sego是一個基於hypervisor的系統，目的在於爲可信的應用程序提供隱私與完整性保證，即使在guest OS compromised的情況下。Sego驗證操作系統的服務，如文件系統，而不是嘗試去替換他們，通過在所有系統設備上聯繫可信的元數據與用戶數據，sego驗證系統服務的效率更高。本文在真實的工作環境中評估了sego的性能，實現了一個kernel fault injector來驗證sego文件系統崩潰與恢復協議。

 

    目前一個趨勢是移除特權軟件的信任，比如說操作系統或者hypervisor。一旦特權軟件是不可信的，系統服務的安全問題有兩種方式來確保：

1. 替代：如haven等將可信軟件的某些地址空間鏈接到受保護的存儲區域中。
2. 驗證：運行中驗證行爲是否與某個標準相匹配。

替代的好處在於應用程序完全控制它的軟件可信計算基。缺點在於大量的庫存在脆弱性，易受攻擊。

這兩種方式都會需要guest OS/hypervisor檢查用戶層程序使用的內存頁，降低系統性能。

 

貢獻：

1. 在可信元數據與不可信數據仍然耦合的情況下，建立一個模型來實現安全計算
2. 針對依賴不可信操作系統所提供的日誌文件系統的應用程序，設計了一個高效的安全數據恢復協議
3. 原形實驗與評估

    

威脅模型：

sego認爲guest操作系統是不可信的。假設guest OS能夠讀或者修改用戶應用程序內存的任意位置；能夠攔截與操控任意IO設備路由進來的數據；當應用程序從系統調用或者中斷返回時，能夠修改控制流；攻擊者能夠crash OS來破壞應用程序。如應用程序在應用安全設置更新前，能夠crash OS。

Sego依賴於可信的hypervisor，假設硬件忠實地執行hypervisor的代碼。一旦一個應用程序信任其他應用程序，sego不進行保護。Sego不保證OS一直可用。

 

架構如圖一所示。可信應用程序在high-assurance process(HAP)中執行。在啓動OS之後，sego hypervisor通過一種HAP能夠證實自身的初始代碼與數據的方式來啓動HAP，如TPM或者軟件SGX。在HAP啓動之後，hypervisor確保HAP的進程上下文、可信的地址空間與OS隔離。Hypervisor使用硬件嵌套頁表來確保HAP地址空間（包括代碼與數據）的隱私與完整性，HAP的地址頁表稱爲S-pages，一旦guest OS嘗試訪問，拋出頁表錯，控制權移交給hypervisor。

libsego用來處理系統調用，可以看成是對C運行庫的一個很小的修改。

每個HAP有一個不可信的trampoline代碼，用來與OS進行交互。

一個流程爲：HAP調用open，libsego將路徑轉換爲一個標識符（OID），發起hypercall，由hypervisor判斷是否允許，若允許libsego將參數複製給Tramp，tramp發起系統調用，獲取返回值之後，libsego驗證結果。

 

    Sego中的頁表分爲三種狀態：

1. 不可信：sego不維護不可信塊的元數據
2. 保留：能夠被不可信的特權軟件直接訪問，但只包含部分元數據。
3. S-pages：不能被不可信特權軟件訪問，sego維護OID與offset。

轉換關係對應的sego接口如下表。

 

    針對OS crash的情況，sego提供了對安全持久化存儲的快速恢復功能。這種安全文件模型相對於普通文件來說：非稀疏的、非shrinking、要求同步。

    表二描述了hypervisor與OS對不同類型的s-files的不一致。

1. myTrustedCloud: Trusted Cloud Infrastructure for Security-critical Computation and Data Management

   1. 摘要

雲計算提供了一個優化的基礎設施來利用與共享計算與數據資源，同時允許按需使用模型，有效地最大化利用率。雲計算同樣提供了計算資源短暫的突然之間的擴展，對很多有時間和經濟約束的社團來說極爲重要。

本文中給出了一個示例，用來將可信計算技術整合到雲（Eucalyptus）中。

 

雲在使用時的問題：

1. 無法確保虛擬機的可信
2. 無法確保數據上傳與管理的可信

原因在於依賴於一個不可信的基礎設施來實例化VM、掛載塊設備以及從web服務中獲取數據對象。用戶不能證實虛擬機，也不能證實他們上傳的鏡像是否與倉庫中的一致。

一個解決方案是私有云，但是私有云要求在硬件、管理以及軟件資源上有更多的投資。

 

Use case

1. 架構

    VM的完整性依賴於三個組件：VM，node controller（NC），storage controller（SC）。

    分三步進行證實：

1. 證實VM：確保VM上運行可信的程序與可信的配置
2. 證實NC：確保只有預期的軟件棧能夠操作VM
3. 證實SC：確保VM被綁定在可信的虛擬存儲上

用戶初始化三個不同的證實會話，驗證所有組件的完整性，整合爲一個最終的證實流程。這樣做有兩個問題：

1. 將雲內部基礎設施暴露給用戶，擴寬攻擊面，違背了VM與hypervisor的隔離原則
2. TTP的單點故障

deep quote（Towards Platform-Independent Trusted Computing）：用戶僅僅初始化一個證實會話，返回的ticket裏包括了這三部分的證實結果。

1.     NC的證實架構

    NC的初始化過程：

1. BIOS中支持TPM，度量物理系統的初始化過程。
2. Trusted Grub用來度量bootstrapping配置、內核與initrd鏡像以及kernel啓動參數。
3. Kernel裏擁有IMA，度量模塊、應用程序與相關的配置文件。

    libTPMs：vTPM的後端驅動

    seaBIOS：爲每個VM實例化vTPM，度量初始的虛擬的硬件組件

    OpenPTS：實現VM的證實過程

    由於NC中kernel的內核被qemu直接加載，因而不存在boot loader。這樣VM的kernel不能再加載前被度量，hash值也無法存入到vTPM中。爲了解決這個問題，本文對qemu的配置firmware進行修改，以便於存儲加載的內核的內存地址。Seabios解析這些內存地址，通過修改後的QEMU的IO來度量加載的模塊並獲取hash值，之後將這些hash值寫入vTPM中。

1. SC的證實架構

1. Trusted Tamper-Evident Data Provenance

   1. 摘要

數據來源經常使用在安全設計和數據分析上，由於起源日誌提供了數據變化的證據，起源日誌的完整性對於整個取證進程的完整性來說也是十分重要的。然而，很少有解決方案能夠完全滿足這些信任要求。本文中，我們提出了一個使用TPM來實現證據防篡改，並且保護數據完整性與機密性的框架。同時，爲了保證可用性，我們將來源日誌可信存儲在備份的服務器上。

 

將數據來源作爲證據應該滿足五個要求：admissibility, authenticity, completeness, reliability, believability.

1. Trusted Virtual Containers on Demand∗

   1. 摘要

基於TPM的可信計算技術希望使用硬件與密碼學變換來向遠程第三方提供一個計算平臺的可信驗證。然而，傳統的可信計算方式受到可擴展性與靈活性的限制。本文通過在OpenSolaris中使用TPM來解決這些缺陷：內核按需創建輕量級的容器，使用DTrace或者其他工具來擴展證實到更多細微運行時屬性，並舉例說明了本文原型應用場景。

 

傳統可信計算的缺陷：

• 可擴展性：一個可信環境能夠多快構建？一個單虛擬主機上能夠建立多少個可信環境？
• Expressiveness：如何處理運行時的動態屬性？
• 靈活性：遠程方是否可以協商對其來說更加重要的屬性？

 

相關工作：

Towards Expressiveness:

• 基於屬性的證實方式，缺陷：依靠TTP將配置映射到屬性；假設OS是策略中立（？）
• 基於編程語義的證實方式
• 作者實驗室：compartmented attestation將證實綁定在SELinux上，但是比較複雜，很難使用。（看參考文獻）

Towards Scalability

• Trusted virtual domains將可信環境擴展到多個機器上。缺點：（？）；每個VM還需要證實他們自己的軟件棧，證實龐大。

Towards Flexibility

• 虛擬化將該問題轉化爲配置不同的VM，然而，這樣要求要證實所需要的虛擬化環境。

Solaris Zones/Containers

    相對於VM來說更加輕量級、啓動更快、開銷更少。

DTrace爲特權程序提供了一個輕量級的方式來檢測其他程序的的執行。

 

1. Verifying Cloud Services: Present and Future

   1. 摘要

隨着基於雲的服務越來越受到私人以及企業的歡迎，雲消費者依舊缺乏一種工具能夠用來證實這些服務按照預期在工作。這些工具應該要考慮諸如功能正確性、服務可用性、可靠性、性能、安全保證等屬性。本文我們調研了在這些方面現有的現有的工作，標識在現有云技術中中提供證實工具的鴻溝。本文也討論如何打破這些鴻溝所面臨的挑戰以及可能的研究方向。

雲計算用戶關注的問題：

1. 可信軟件與服務器身份：服務運行在一系列正確的服務器集合，並擁有正確軟件棧上
2. 功能正確行：服務啓動之後，行爲是否與所希望的一致
3. 性能與可靠：效率如何？可靠？可用？
4. 安全：服務遵守安全策略

    

應對這些問題的幾個研究領域

1. 驗證強服務身份（Verification of Strong Identities）

雲服務提供商不能保證分發給用戶的服務與實現一致。有可能有云管理員的誤操作、其他雲租戶的誤用，這些都有可能導致服務的誤配置。問題爲如何允許雲服務商證實部署的服務是否符合預期，可能的技術是可信計算。

1. 驗證雲服務的功能屬性（Verification Functional Properties of Cloud Services）

用戶需要得到保證：雲服務與雲提供商給出的功能標準一致。本文給出了一個方案允許用戶能夠可擴展地驗證服務的完整性，而不需要依賴於一箇中心簽證機構，或者訪問真正的實現代碼。基本思想是將驗證過程解耦成三個階段：test suite generation（黑盒子測試技術，覆蓋標準裏給出的行爲）/test suite execution/validation of the results（樣本測試）。

1. 驗證雲存儲服務（Verification of Cloud Storage Services）
2. 性能與可靠
3. 面向安全的非功能屬性驗證

 

各個研究領域的相關工作、挑戰與可能的方案

1. 驗證強服務標識

要解決的問題：雲提供商如何確保在雲節點上運行的軟件與實現的服務之間有個強的身份標識。

假定S是CSP給出的服務實現，S'是雲主機上的服務實例，如何確保在整個生命週期內滿足S＝S'。

爲了滿足強服務標識，雲提供商應當給出可信容器。可信容器承載服務，並將其與其他租戶或者雲管理員隔離開來。當遷移發生時，驗證目的地是否是一個可信容器，再通過加密通道遷移數據。

可信容器的實現語義可通過特權軟件系統，特權軟件系統使得管理員與其他租戶都不能訪問服務實例的狀態。CloudVisor藉助嵌套的虛擬化技術來保護Xen的guest VM的完整性與機密性。問題因而轉化爲如何讓遠程第三方驗證雲節點執行了一個可信的軟件系統。這點可以通過可信計算的遠程證實實現。

 

現有工作：

• IaaS上的強軟件標識：

  架構：Santos（Towards Trusted Cloud Computing. In HotCloud, 2009）

  加固的hypervisor：CloudVisor（CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization. In SOSP, 2011）

• 藉助可信計算的系統：

  Schiffman給出一個系統允許從雲外部對雲節點的hypervisor與VM鏡像執行遠程證實（Seeding Clouds with Trust Anchors. In WCCS, 2010.）

  其改進版本是Excalibur，防止由於TPM效率導致的瓶頸問題，並將數據seal到策略上，使得只有滿足這些策略的節點才能unseal。如將VM鏡像seal在CloudVisor上，則只有運行CloudVisor的節點才能實例化這個VM鏡像。（Policy-Sealed Data: A New Abstraction For Building Trusted Cloud Services. In USENIX Security, 2012）

• 實現可信容器的系統：

  Nexus 在進程層次上提供可信容器概念，不需要運行VMM。(Logical Attestation: AnAuthorization Architecture for Trustworthy Computing. In SOSP, 2011.）

  Maniatis將可信容器作爲沙箱，更適合網頁應用程序的隔離。（Do You Know Where Your Data Are? Secure DataCapsules for Deployable Data Protection. In HotOS, 2011.）

   

  面對的挑戰：

• 高層級PaaS容器概念：
• 與PaaS back-end集成
• 分佈式與遷移PaaS服務實例

1. Attestation Transparency: Building secure Internet services for legacy clients

   1. 摘要

網絡服務提供了豐富的功能，然而他們的使用引起了用戶對隱私、安全以及完整性的擔心。這是由於缺少如何確保server端正在運行的符合用戶預期。在最壞的情況下，這些服務可能受到內部攻擊。我們使用遠程證實來確保服務的規劃設計。我們討論了證書透明性來分發關於服務是否存在、服務正在處理什麼事件等的信息。總之，本文給出了一個允許傳統的客戶端來獲取網絡服務的安全保證。

 

問題：

在桌面平臺上，用戶能夠知道運行的軟件是不是他們所希望的版本，知道軟件的行爲與機制來防止對他們數據的非授權訪問以及非授權修改。雲服務不能提供相似的保證，從而引起了用戶對隱私、安全以及完整性的擔心。

本文聚焦於如何防止內部攻擊，方法是使用透明性來抵禦未授權的訪問。使用硬件支撐的密封存儲來確保用戶的數據以加密的方式存儲，構建機制來確保內部不能修改或者往軟件中加入後門。

 

貢獻：

1. 內部攻擊保護：給出瞭如何構建安全網絡服務。這些服務提供對計算與用戶數據的完整性與機密性，能夠抵禦內部攻擊，功能能夠被遠程證實。
2. 策略與更新機制：允許服務更新，對於用戶來說這是透明的，同時確保服務的完整性與機密性。
3. 傳統的客戶端支持：證實透明性來防止服務提供者祕密地改變他們的服務。

 

1. 架構

   1. 威脅模型

假設承載這些服務的服務器使用了一些安全的enclave技術，用來防止敵手訪問或者修改enclave中的數據或者代碼。允許敵手擁有主動的網絡攻擊者的所有能力，能夠控制承載這些服務機器的所有non-enclave軟件，能夠運行自己的軟件來僞裝成真實的服務。假設用戶的客戶端是安全的。

1. 設計

將所有的服務代碼運行在enclave中，包括TLS session的建立、請求處理以及存儲。使用seal存儲來防止惡意內部攻擊者來讀取或者修改數據。在數據離開enclave前爲數據加密。

利用證書透明來分發這些與independently-auditable的證實。Certificate Transparency（後面簡稱CT）是google提倡的爲了提高SSL/TLS上更高信賴度的新技術。現在已被RFC化（RFC6962），用於防止證書的誤發行的技術而備受注目。CT是起着每當CA機構簽發證書，將所有的證書的簽發行爲都記錄到審計日誌作用的。主要是網站運營者，域名管理者之類的可以通過這個審計日誌服務器來確認自己的域名對應的證書有無被其他CA機構簽發，以此來防止非正常簽發的可信證書被他人濫用。

雖然CT看起來僅僅起着提高證書的可信賴度，但並不意味着沒有CT的其他的證書檢測不可信。

1. 策略模型

爲了證實這個服務，必須要證實1）服務的代碼正確的實現了預期的行爲2）在這個機器上沒有其他的程序能夠有接口來操作這個服務的代碼或者觀察它的內存。Enclave保證了第二點，對於第一點來說，如何爲大多數普通用戶設計模型？

1. 安全服務設計

安全服務架構如圖3所示，提供的接口：

1. 通過TLS提供安全網絡接口
2. 安全存儲接口
3. 證實接口
4. IPC接口

1. Remote attestation for low-end embedded devices- the prover's perspective

   1. 摘要

嵌入式設備的大規模使用使得其越來越成爲黑客攻擊的目標。針對嵌入式的普遍的黑客攻擊方式是是通過遠程的惡意程序。一個有效地防禦措施是遠程證實，在這種機制中，允許一個可信的，通常是一個遠程的驗證者來檢測一個不可信的、有可能被攻擊的設備prover的內部狀態。

儘管有很多的先前工作，遠程證實依舊是一個很熱的研究問題。大部分的證實機制也僅僅考慮這種verifier是可信的而prover是不可信的場景。與之相反的場景（prover是良性的，而verifier是不可信的）通常被迴避。本文考慮到了prover的安全，包括假扮verifier、DDoS攻擊以及重放攻擊，所有的這些攻擊方式將會導致對prover的證實功能的未授權的調用。我們認爲針對這些問題對prover的保護必須是任何遠程證實方法的一個很重要的部分。我們針對這種場景構建了一個新的roaming敵手模型，並給出了面臨這種威脅的一些trade-offs。我們同時也給出了在最小化額外要求的需要確定的新的特徵與方法。

 

1. 出發點：

攻擊者有可能可以通過證實協議來對prove進行攻擊。比如說僞造的verifier能夠一直調用證實協議來引起prover的DDoS攻擊，這種攻擊方式消耗prover資源，影響prover的主要工作模塊或者服務。

1. 貢獻：

本文標識並且分析對運行在低端嵌入式設備上的prover的DOS攻擊。首先，本文給出了證實協議如何來應對一個使用已知技術的外部敵手。然後，我們調研了一個更老練的roaming敵手來攻擊prover並且通過一種標準的證實方法無法檢測的方式來操作prover。這種攻擊更加危險，因爲roaming敵手能夠擦除所有他出現的痕跡。之後，我們證實了兩種通過在低端嵌入式設備上加上很小的硬件假設，來減輕roaming敵手威脅的兩種方式，並且進行具體實現。

 

這篇的相關工作挺重要的~可以一個個看~

 

1. 敵手模型：

verifier（Vrf）向prover（Prv）發起證實請求（attreq），Prv上有一個可信的anchor來度量Prv的狀態，這個anchor與Vrf有一個共享密鑰（K_attest）。

如果敵手僞造Vrf導致Prv執行證實，這會產生一些額外的開銷。

首先，執行證實來計算一個響應包括了計算針對整個內存的消息認證碼（MAC），表一是使用SHA1-HMAC計算耗時。對512KB的RAM進行hash消耗754.032ms（怎麼算的。。。。）。

其次，目前的低端設備證實技術假設在運行證實的過程中不能發生中斷。因此，對證實的惡意調用對prover的主功能模塊是不利的。

這種DoS攻擊的主要原因是執行證實的prover與verifier的工作負載是不對稱的。

 

敵手：

不能執行物理攻擊。

1. 外部敵手Adv_ext：可以控制Prv與Vrf之間的所有交互。能夠丟棄、插入、延遲消息，但是不能操縱Prv的內部狀態。
2. Roaming敵手Adv_roam：除了外部敵手的能力之外，還能夠用惡意程序來感染Prv並且可能擦除自身痕跡。假設其主要目的是爲了實現DoS。可以分三步實現：1）偷聽Vrf-Prv之間的證實交互消息。2）通過惡意程序攻擊Prv，改變其本地狀態，擦除自身痕跡。這一步通常改變的是Prv的動態數據，這種是不能被序列化得證實方式檢測到3）回覆之前的請求信息。

1. 對策

   1. 應對Adv_ext

      1. 認證Verifier請求

兩種方式：公鑰或者對稱密鑰

公鑰加密對於嵌入式設備來說成本太高。表一中顯示了使用ECC進行verify的時間是170ms，因而對於這種方式可以說在某種程度上本身就是造成了DoS。所以排除使用公鑰加密。

對稱加密來驗證SHA1的HMAC能夠在0.43ms完成。塊加密方式比如AES更快，使用輕量級的塊加密，如speck，能減少到0.015ms。

1. 處理reply

幾種檢測重放、重排序以及延時的攻擊：

1. nonces：檢測replay，需要維護nonce的history
2. counters：證實請求擁有一個單調增的計數器，prover每次接收當且僅當包的counter=自身的counter+1，檢測重排序
3. Timestamps：假設有同步機制來實現時間戳，檢測replay、reordered、delay攻擊

1. 應對Adv_roam

應對Adv_ext的方式在應對Adv_roam是不可行的

1. counters：可以修改prover維護的counter，比如說減一，從而進行重放攻擊
2. Timestamps：可以重置prover自身的時鐘

相對而言，timestamps攻擊要求更高，比如說將時鐘後退t，那麼必須延遲t時重發請求，而且重置時間會引起與外部的不一致，可能會被發現。

1. 保護密鑰、counter與時鐘

爲了應對Adv_roam，必須保護密鑰、counter與時鐘。K_attest必須維護機密性、不可修改以及對正確的Code_attest可讀。Counter與時鐘必須寫保護。這些保護需要有很小的硬件安全機制支持。

1. 實現

限制對系統關鍵資源（密鑰、counter、時鐘）的訪問原語稱爲執行感知的內存訪問控制（EA-MAC）。有很多先前的方式用來解決這個問題。

實現原型基於三個組件：ROM、EA-MAC、安全boot。Figure1是兩個原型版本，均基於TrustLite證實架構。EA-MPU的內存訪問控制規則將保護系統組件，如確保只有Code_attest能夠讀寫counter。系統通過secure boot啓動，確保啓動時系統軟件是可信的，從而設置EA-MPU規則並鎖定以不允許修改。Code_attest同樣寫在ROM中，從而不能改變。

 

 

1. Things, Trouble, Trust: On Building Trust in IoT Systems

   1. 摘要

物聯網目前面臨着很多大量的安全和隱私挑戰，其中一個突出的問題是如何在遠程的IoT設備上建立可信。針對這個問題一個典型的方案是利用遠程證實，遠程證實是一個不同的安全服務，目的在於弄清一個可能被攻擊到的遠程設備的當前狀態。遠程證實覆蓋了從重量級的基於硬件的安全技術，到相對輕量級的基於軟件的技術範圍，也包括了一些混雜了軟件（控制流完整性）、以及硬件特徵（PUFs）等的技術。本文從IoT的視角上調研了藝術級的證實技術的landscape，並且說明其中的大多數方案將在IoT可信建立中擔任重要的角色。

1. 介紹

IoT一個重要的特徵在於它包括了大量了低成本的、資源受限的設備，大量的設備引起的這些約束導致了重要的安全和隱私挑戰。一個重要的挑戰在於面對惡意軟件的脆弱性。儘管惡意軟件不是一個新的威脅，IoT卻加寬、放大了攻擊表面。這些威脅清晰的催發了驗證遠程IoT設備是否處於一個預料之中的狀態。

本文兩個主要目標：

1. 提供一個對在IoT中完成證實的overview
2. 展示多種類型的證實能夠適應這種環境設定

 

證實可以分爲這兩個方面：

1. 獲取prover的當前狀態的進程（度量進程）
2. 將證據傳輸給verifier的協議

 

威脅模型：

最普遍的威脅模型是一個受到攻擊的prover想要謊報當前狀態給verifier，對應有很多種敵手類型：

1. 遠程敵手：利用惡意軟件遠程影響prover
2. 本地敵手：偷聽、妨礙prover的通信過程
3. 物理非侵入式敵手：能夠執行側信道攻擊
4. 祕密的物理侵入式敵手：能夠物理地抓取prover存儲的任何信息
5. 物理侵入式敵手：除了物理抓取prover存儲的任何信息外，還能夠修改狀態或者硬件組件

 

當代的針對於IoT設備的研究聚焦於如何減輕遠程敵手的威脅。這主要有三個原因：

1. 最普遍的類型，由於來源於遠程，最容易防衛
2. 潛在攻擊範圍最大
3. IoT設備不能承受安全硬件的開銷

 

1. 基於安全硬件的證實

基於TPM的證實除了對物理侵入式敵手外，其他都能防禦

 

1. 動態可信根

基於TPM的證實一個很大缺點在於：TPM Quote時有着潛在的大量的度量值，這使得驗證一個quote極耗時間。動態可信根DRTM就是用來解決這個問題。DRTM允許讀兩個呢從用戶指定的任何點開始。在DRTM啓動之後，平臺將執行一個局部的CPU重置，重置PCR的子集到一個初始狀態。

 

1. 基於SGX的證實

對DRTM的概念進行擴展，SGX爲應用程序軟件提供了一個硬件加強的隔離執行環境。Enclave隔離並且保護程序內容，避免被其他軟件干擾，並且提供了enclave之間或者與遠程的證實方式。

 

1. 基於屬性的證實

之前提到的幾種方式均屬於二進制證實，因爲證實證據基於軟件二進制。二進制的證實方式是很脆弱的，任何配置的改變或者軟件升級將會導致不同的二進制hash值，即使prover依舊是處於一個可信的狀態。驗證者因此要求維護一個所有可信值得列表。爲了減輕這個約束的影響，基於屬性的證實方式將二進制度量轉換爲對於系統屬性的一些陳述。

 

基於硬件的證實方式要求有一個明確的可信anchors，比如TPM或者SGX功能的CPU。然而，由於成本以及複雜性的考慮，IoT系統基本不可能擁有這些trust anchors.

 

1. 基於軟件的證實方式

基於軟件的方式沒有硬件可信根，因而，不能假設prover上有安全的地方來保存secrets，也不能依賴於prover執行了可信的代碼。相反，基於軟件的證實方式利用側信道信息，一如說執行某個特定計算prover所需要的時間。

許多文獻裏研究了基於軟件的證實方式，Pioneer使用一個函數計算了設備的內存的校驗值，這種方式會有運行時的反作用，因爲這個函數的每次使用帶來了額外的時間消耗，比如說延遲。基於時間的校驗值也應該被應用到嵌入式設備中，然而也存在許多脆弱點。

通常來說，所有現有的基於軟件的證實技術對敵手能力作出了很強的假設，也僅僅在verifier與prover直接通信的情況下才有效。這是因爲：

1. Multi-hop必然會導致來回傳輸的延遲，對於任何基於時間的度量都會引入誤差
2. Verifier必須能夠檢測到本地敵手的攻擊，以防其與被攻擊的prover合謀。

如果能夠保證這兩點，基於軟件的證實方式同樣能夠應對上面提到的所有敵手模型。值得注意的是，基於軟件證實在網絡環境中不可行。

 

1. 混合證實

爲了克服軟件證實帶來的限制，大量混合證實方案被提出。混合證實的目標在於，在最小修改硬件的情況下能夠應對除了物理侵入式敵手外的所有類型敵手，而且是在網絡環境中。

1. 最小化可信anchors

SMART架構爲低端設備提供了動態可信根，沒有指定特殊的內存管理或者保護特徵。SMART架構有四個組件：

1. 在ROM中的一個證實只讀內存代碼區域
2. ROM中保存的一個只能被SMART訪問的密鑰存儲區域
3. MCU訪問控制，使得非SMART不能訪問安全密鑰存儲以及中斷SMART代碼執行
4. 如果這些組件有報錯，則進行充值與內存擦除

對於verifier來說，ROM中的證實代碼會計算prover的內存的校驗值，並返回給verifier。

 

TrustLite是低端嵌入式系統中的一個普遍的安全架構，允許一些特殊軟件模塊（trustlets）與OS獨立的隔離。TrustLite給出了EAMPU（執行感知的內存保護單元）作爲內存保護。EAMPU確定只有trustlet的代碼能夠訪問trustlet內容。

 

TyTAN通過允許在運行時動態加載與卸載應用程序、實時調度保證與安全的IPC等提供了更靈活地架構。

 

1. 基於PUF的證實

基於軟件證實方式要求prover與verifier直接相連，也不能驗證底層硬件。而對於SMART、TrustLite而言，如果考慮到物理敵手，由於能夠直接獲取到prover的key，敵手很容易來僞造或者克隆prover。

PUF（Physically Unclonable Function）是一個特殊的物理結構，能夠利用芯片製造商的側信道，根據每個輸入生成一個唯一的與硬件相關的輸出。PUF能夠將正式綁定到一個特定prover的指定硬件上，因而可以在混合證實進行利用以替換掉訪問受限的設備密鑰。

然而，環境對於PUF的影響較大，比如說電力供應波動等。PUF要求：

1. 一個低成本、低消耗的PUF的註冊過程
2. 維護一個很大的PUF數據庫

1. 基於控制流圖的證實

代碼的可信還包括運行時行爲，靜態的證實方案只考慮二進制代碼的可信而忽略他們的運行時，從而不能檢測到劫持程序的控制流從而使得軟件崩潰的錯誤，比如說修改堆棧來轉移控制流。有論文中給出了使用代碼重用技術的內存攻擊方式，在不用注入惡意代碼的情況下，使得良性代碼帶上惡意程序。

本文作者嘗試着在嵌入式設備上提供一個運行時的證實機制，該機制能夠提供對程序執行路徑精確的證實。程序的執行路徑能夠被加密成執行指令的分支、或者是累積哈希。在這兩種情況中，執行路徑都可以被認爲是軟件執行的指紋。

運行時證實相對於其他運行時防衛技術有一些優勢，比如說控制流圖完整性（CFI）。CFI強制實施以確保沒有違背控制流情況發生，而運行時證實將報告執行的控制流。

1. 挑戰

   1. 能夠處理大量的IoT設備
   2. 處理異構設備
   3. 嵌入式設備資源受限

   1. 可擴展性

大多數論文聚焦於一個prover與一個verifier，事實是有很多情況要求一個verifier證實一個prover組（集羣）。

第一個嘗試解決集羣證實的論文是SEDA: Scalable Embedded Device Attestation。對應的兩點要求是：1）能夠提供一個比對每個節點進行證實更有效的方式來證實一個集羣，2）與現有的完整性證實方案獨立。

初始化階段：D8加入集羣，對所有鄰居進行join協議，這將與每個鄰居建立一對證實密鑰。

證實的原則是遞歸進行。Verifier選擇一個節點，如D1，發送一個nonce，D1產生一個會話標識q。通過attdev協議，D1將證實請求（N，q）發送給所有鄰居，等待回覆，以此類推，從而形成一個以D1爲根的樹，證實報告將從葉子節點匯聚到根節點。

1. prover的視角

真實環境中，敵手可能扮演成verifier，形成對prover的未認證的證實，從而進行DDoS攻擊。