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
July 18, 2017 karim.eldefrawy@sri.com
HRL Labs (Currently at SRI) UC Irvine UC Irvine
2
3
○ Comm interfaces (USB, CAN, Serial, WiFi, Ethernet …) ○ Analog to digital converters
○ Secure updates, deletion/erasure and resetting
○ Trusted Verifier : powerful entity ○ Untrusted Prover : embedded device
Verifier Prover
1) challenge 3) response 2) checksum (e.g. MAC or Signature) 4) verify
4
○ Secure hardware (e.g., TPM) ○ Overkill for medium/low-end IoT/embedded devices
○ A.k.a. timing-based attestation ○ Does not support multi-hop communication ○ Underlying assumptions (seriously) challenged [1]
○ Minimal hardware support for secure RA
[1] C. Castellucia, et al. On the difficulty of Software-Based Attestation of Embedded Devices, CCS 2009.
5
○ Secure hardware (e.g., TPM) ○ Overkill for medium/low-end IoT/embedded devices
○ A.k.a. timing-based attestation ○ Does not support multi-hop communication ○ Underlying assumptions (seriously) challenged [1]
○ Minimal hardware support for secure RA
[1] C. Castellucia, et al. On the difficulty of Software-Based Attestation of Embedded Devices, CCS 2009.
6
7
○ 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.
8
** K. Eldefrawy, et al. SMART: Secure & Minimal Architecture for (Establishing a Dynamic) Root ofTrust, NDSS’12.
9
○ Comm interfaces (USB, CAN, Serial, WiFi, Ethernet …) ○ Analog to digital converters
Properties 1) Exclusive Access to Key 2) No Leaks 3) Immutability 4) Uninterruptability 5) Controlled Invocation
10
Properties 1) Exclusive Access to Key 2) No Leaks 3) Immutability 4) Uninterruptability 5) Controlled Invocation Hardware Requirement ★ ROM ★ MCU (bus) access controls
11
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
13
kernel ○ Spec Impl Binary
enforcement
14
kernel ○ Spec Impl Binary
enforcement
access controls in SMART
Process
15
kernel ○ Spec Impl Binary
enforcement
access controls in SMART
Process
16
★ Exclusive Access (E/A) to key ★ No leaks ★ Immutability ★ Uninterruptability ★ Controlled invocation
★ E/A to key ★ E/A to virtual address space ★ E/A to executable ★ Secure boot of seL4 and attestation process ★ Highest priority ★ E/A to Thread Control Block (TCB)
17
○ Contains capabilities to all objects, e.g. IPC, memory pages, and threads ○ Runs with highest scheduling priority ○ Manages the rest of user-space
18
○ Contains capabilities to all objects, e.g. IPC, memory pages and threads ○ Runs with highest scheduling priority ○ Manages the rest of user-space
○ Executable/Key ○ Working virtual memory ○ TCB
19
seL4 Kernel PRAtt PR1 PR2 Clock Secure Boot
Bootloader verifies and starts seL4 microkernel Kernel verifies and passes control to PRAtt PRAtt spawns PR1 and PR2 Verifier sends an attestation request to PRAtt PRAtt performs att. and reports back to verifier 1 4 5
MM I/O RAM/Flash ROM
2 3
Verifier
1 2 3 4 5
20
https://boundarydevices.com/product/sabre-lite-imx6-sbc/ http://www.hardkernel.com/main/products/prdt_info.php
21
22 HYDRA with net and libs HYDRA w/o net stack HYDRA w/o net and libs seL4 Kernel Only Lines of Code 105,360 68,490 11,938 9,142 Exec Size 574KB 476KB N/A 215KB Operations (I.MX5-SabreLite at 1GHz) 1MB of Memory 20KB of Memory Number of Cycles Percentage Number of Cycles Percentage 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%
23
24
25
○ Motivate using hardware-enforced secure boot
26
○ Motivate using hardware-enforced secure boot
○ 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
28
seL4 seL4 + Signature seL4 + Signature
Rod Ziolkowski, i.MX Applications Processor Trust Architecture, 2013
29
○ Bogus requests ○ Delay, replay or reordering attacks
○ 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.
30
○ When PRAtt starts, it loads T0 that was saved before the last reboot. ○ When the first request arrives, compare its timestamp (T1) with T0 ○ Verify request. If success, keep track of T1 and start counter. ○ TS = T1 + counter value ○ Periodically store TS
31
➢ Emulate certain properties that were previously only realizable using hardware features
➢ seL4 assumptions ➢ Secure boot ➢ Timestamp generation
32
34
KAttes
t
seL4 Kernel
PRAtt Timer Secure Boot
MM I/O RAM/Flash ROM
35
KAttes
t
seL4 Kernel PRAtt Timer Secure Boot MM I/O RAM/Flash ROM T0
36
KAttes
t
seL4 Kernel PRAtt Timer Secure Boot MM I/O RAM/Flash ROM T0
Verifie r
@ T1
37
KAttes
t
seL4 Kernel PRAtt Timer Secure Boot MM I/O RAM/Flash ROM T0
Verifie r
T1
38
KAttes
t
seL4 Kernel PRAtt Timer Secure Boot MM I/O RAM/Flash ROM T0
Verifie r
T1 TS = T1 + Timer
39
40
41