HYDRA: HYbrid Design for Remote Attestation (Using a Formally - PowerPoint PPT Presentation

HYDRA: HYbrid Design for Remote Attestation (Using a Formally Verified Microkernel) Karim Eldefrawy , Norrathep Rattanavipanon, Gene Tsudik HRL Labs UC Irvine UC Irvine (Currently at SRI) July 18, 2017 karim.eldefrawy@sri.com

IoT/CPS/ES 2

Low/Medium-end Embedded Systems ★ CPU ★ Clock ★ Program and data memory ★ In addition to: Comm interfaces (USB, ○ CAN, Serial, WiFi, Ethernet …) Analog to digital converters ○ 3

Remote Attestation (RA) ★ Remote verification of internal state of a prover by a verifier Secure updates, deletion/erasure and resetting ○ ★ Challenge-response protocol between ○ Trusted Verifier : powerful entity ○ Untrusted Prover : embedded device 1) challenge 2) checksum Verifier Prover (e.g. MAC or Signature) 3) 4) verify response 4

Design of RA ★ Hardware-only Attestation Secure hardware (e.g., TPM) ○ ○ Overkill for medium/low-end IoT/embedded devices ★ Software-only Attestation ○ A.k.a. timing-based attestation ○ Does not support multi-hop communication ○ Underlying assumptions (seriously) challenged [1] ★ Hybrid Attestation Minimal hardware support for secure RA ○ [1] C. Castellucia, et al. On the difficulty of Software-Based Attestation of Embedded Devices, CCS 2009. 5

Design of RA ★ Hardware-only Attestation Secure hardware (e.g., TPM) ○ ○ Overkill for medium/low-end IoT/embedded devices ★ Software-only Attestation ○ A.k.a. timing-based attestation ○ Does not support multi-hop communication ○ Underlying assumptions (seriously) challenged [1] ★ Hybrid Attestation Minimal hardware support for secure RA ○ [1] C. Castellucia, et al. On the difficulty of Software-Based Attestation of Embedded Devices, CCS 2009. 6

Adversary Model ○ Remote: exploits vulnerabilities and injects malware over the network. Local: located sufficiently close to prover and can ○ eavesdrop on, and manipulate the communication channel. ○ Physical: has full (local) physical access to prover and its hardware and can perform physical attacks, e.g., use side channel to extract and/or modify keys and values in memory. 7

SMART ** First hybrid design of remote attestation for low-end microcontrollers (MCUs) ** K. Eldefrawy, et al. SMART: Secure & Minimal Architecture for (Establishing a Dynamic) Root ofTrust, NDSS’12. 8

Low/Medium-end Embedded Systems ★ CPU ★ Clock ★ Program and data memory ★ In addition to: Comm interfaces (USB, ○ CAN, Serial, WiFi, Ethernet …) Analog to digital converters ○ 9

SMART Properties 1) Exclusive Access to Key 2) No Leaks 3) Immutability 4) Uninterruptability 5) Controlled Invocation K. Eldefrawy, et al. Secure & Minimal Architecture for (Establishing a Dynamic) Root of Trust, NDSS 2012. A. Francillon, et al. A Minimalist Approach to Remote Attestation, DATE 2014. 10

SMART Properties 1) Exclusive Access to Key 2) No Leaks 3) Immutability 4) Uninterruptability 5) Controlled Invocation Hardware Requirement ★ ROM ★ MCU (bus) access controls 11

SMART Properties 1) Exclusive Access to Key 2) No Leaks 3) Immutability 4) Uninterruptability 5) Controlled Invocation Hardware Requirement ★ ROM ★ MCU (bus) access controls Can be emulated using a formally verified software component 12

Hybrid RA Design using seL4 13

seL4 What is it? ● Formal verification of the OS kernel Spec Impl Binary ○ ● Capability-based access control ● Formally proven access control enforcement 14

seL4 What is it? Why? ● Formal verification of the OS ● Emulate hardware-enforced kernel access controls in SMART Spec Impl Binary ○ ● Provide isolation of Attestation ● Capability-based access control Process ● Formally proven access control enforcement 15

seL4 What is it? Why? ● Formal verification of the OS ● Emulate hardware-enforced kernel access controls in SMART Spec Impl Binary ○ ● Provide isolation of Attestation ● Capability-based access control Process ● Formally proven access control enforcement How? Map SMART properties into seL4 configuration 16

Deriving Configuration SMART Properties Att Process Config. ★ E/A to key ★ Exclusive Access (E/A) to key ★ E/A to virtual address ★ No leaks space ★ Immutability ★ E/A to executable ★ Uninterruptability ★ Secure boot of seL4 and ★ Controlled invocation attestation process ★ Highest priority ★ E/A to Thread Control 17 Block (TCB)

Our Approach - HYDRA ★ Run Attestation Process ( PR Att ) as initial user-space process ○ Contains capabilities to all objects, e.g. IPC, memory pages, and threads ○ Runs with highest scheduling priority ○ Manages the rest of user-space 18

Our Approach - HYDRA ★ Run Attestation Process ( PR Att ) as initial user-space process ○ Contains capabilities to all objects, e.g. IPC, memory pages and threads ○ Runs with highest scheduling priority ○ Manages the rest of user-space ★ Only spawn new process that does not contain capabilities to PR Att ’s: ○ Executable/Key ○ Working virtual memory ○ TCB 19

seL4 Kernel 2 4 PR Att Verifier 3 RAM/Flash 5 PR 1 Bootloader verifies and starts seL4 microkernel 1 1 PR 2 Kernel verifies and passes control to PR Att 2 PR Att spawns PR 1 and PR 2 3 Verifier sends an attestation request to PR Att 4 PR Att performs att. and reports back to verifier 5 MM I/O Clock ROM Secure Boot 20

Implementation ➢ Prototype on I.MX6-SabreLite and Odroid-XU4 https://boundarydevices.com/product/sabre-lite-imx6-sbc/ http://www.hardkernel.com/main/products/prdt_info.php ➢ Existing secure boot (High Assurance Boot - HAB) mechanism in Sabre Lite 21

Performance 1/3 HYDRA with HYDRA w/o HYDRA w/o seL4 Kernel net and libs net stack net and libs Only Lines of Code 105,360 68,490 11,938 9,142 Exec Size 574KB 476KB N/A 215KB Operations 1MB of Memory 20KB of Memory (I.MX5-SabreLite Number of Cycles Percentage Number of Cycles Percentage at 1GHz) VerifyRequest 1,604 0.01% 1,604 0.29% Retrieve Memory 3,221,307 10.7% 45,624 8.21% MacMemory 26,880,057 89.29% 508,334 91.5% Total 30,102,968 100% 555,562 100% 22

Performance 2/3 23

Performance 3/3 24

Lessons Learned 25

Challenges when using seL4 Formal verification of seL4 assumes: ★ Proper initialization of the kernel ○ Motivate using hardware-enforced secure boot 26

Challenges when using seL4 Formal verification of seL4 assumes: ★ Proper initialization of the kernel ○ Motivate using hardware-enforced secure boot ★ Correct behavior of the underlying hardware Sol: Run seL4 on top of a formally verified processor ○ ○ But does such hardware exist? Not yet … but possible in the future, e.g. CHERI ISA [1] based on ○ Bluespec SystemVerilog [2] [1] R. N. Watson, et al. Capability hardware enhanced risc instructions: Cheri instruction-set architecture, 2016. [2] R. Nikhil and K. Czeck, BSV by Example. CreateSpace Independent Publishing Platform, 2010 27

Platform Specific Secure Boot ★ Requires configurable/programmable secure boot ○ Not easy to find in commercial development boards ★ SabreLite’s High Assurance Boot (HAB) ○ Based on a digital signature scheme ○ Configurable through ROM APIs 28

seL4 seL4 + seL4 + Signature Signature 29 Rod Ziolkowski, i.MX Applications Processor Trust Architecture, 2013

Ensuring Freshness of Attestation Requests ★ Computational Denial-of-Service from: ○ Bogus requests ○ Delay, replay or reordering attacks ★ Solution: Verify requests! Requires timestamp generated by a reliable read-only clock. ○ ○ Read-only property can be enforced using seL4’s capability. ○ Reliable property requires a (semi-synchronous) real-time clock. F. Brasser, et al. Remote Attestation for Low-End Embedded Devices: the Prover’s Perspective, DAC 2016. 30

Ensuring Freshness of Attestation Requests ★ No real-time clock driver implementation in Sabre Lite. ★ Workaround by generating pseudo-timestamp using a counter + a secondary storage When PR Att starts, it loads T 0 that was saved before the last reboot. ○ ○ When the first request arrives, compare its timestamp ( T 1 ) with T 0 Verify request. If success, keep track of T 1 and start counter. ○ ○ TS = T 1 + counter value Periodically store TS ○ 31

In Summary ❖ First hybrid design for Remote Attestation using a formally verified microkernel (seL4) Emulate certain properties that were previously only realizable using ➢ hardware features ❖ Prototype on two commercially available platforms ❖ Challenges seL4 assumptions ➢ Secure boot ➢ Timestamp generation ➢ 32

Questions?

References 34

seL4 Kernel PR Att RAM/Flash K Attes t MM I/O Timer ROM Secure Boot 35

seL4 Kernel PR Att RAM/Flash K Attes t T 0 MM I/O Timer ROM Secure Boot 36

seL4 Kernel @ T 1 Verifie PR Att r RAM/Flash K Attes t T 0 MM I/O Timer ROM Secure Boot 37

seL4 Kernel Verifie PR Att r RAM/Flash K Attes t T 1 T 0 MM I/O Timer ROM Secure Boot 38

seL4 Kernel Verifie PR Att r RAM/Flash K Attes t T 1 T 0 TS = T 1 + Timer MM I/O Timer ROM Secure Boot 39