HYDRA: HYbrid Design for Remote Attestation(Using a Formally Verified Microkernel)

Karim Eldefrawy, Norrathep Rattanavipanon, Gene Tsudik

July 18, 2017karim.eldefrawy@sri.com

HRL Labs (Currently at SRI)

UC Irvine UC Irvine

IoT/CPS/ES

2

3

★ CPU★ Clock★ Program and data memory★ In addition to:

○ Comm interfaces (USB, CAN, Serial, WiFi, Ethernet …)

○ Analog to digital converters

Low/Medium-end Embedded Systems

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

Verifier Prover1) challenge

3) response

2) checksum (e.g. MAC or Signature)

4) verify4

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

7

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.

SMART** First hybrid design of remote attestation for low-end microcontrollers (MCUs)

8

** K. Eldefrawy, et al. SMART: Secure & Minimal Architecture for (Establishing a Dynamic) Root ofTrust, NDSS’12.

9

★ CPU★ Clock★ Program and data memory★ In addition to:

○ Comm interfaces (USB, CAN, Serial, WiFi, Ethernet …)

○ Analog to digital converters

Low/Medium-end Embedded Systems

SMART Properties1) Exclusive Access to Key2) No Leaks3) Immutability4) 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 Properties1) Exclusive Access to Key2) No Leaks3) Immutability4) Uninterruptability 5) Controlled Invocation

Hardware Requirement★ ROM★ MCU (bus) access controls

11

SMART Properties1) Exclusive Access to Key2) No Leaks3) Immutability4) Uninterruptability 5) Controlled Invocation

Hardware Requirement★ ROM★ MCU (bus) access controls

Can be emulated using a formally verified software component12

Hybrid RA Design using seL4

13

What is it?● Formal verification of the OS

kernel ○ Spec Impl Binary

● Capability-based access control● Formally proven access control

enforcement

seL4

14

What is it?● Formal verification of the OS

kernel ○ Spec Impl Binary

● Capability-based access control● Formally proven access control

enforcement

seL4Why?

● Emulate hardware-enforced access controls in SMART

● Provide isolation of Attestation Process

15

What is it?● Formal verification of the OS

kernel ○ Spec Impl Binary

● Capability-based access control● Formally proven access control

enforcement

seL4Why?

● Emulate hardware-enforced access controls in SMART

● Provide isolation of Attestation Process

How?Map SMART properties into seL4 configuration

16

Deriving Configuration

SMART Properties★ Exclusive Access (E/A) to key★ No leaks★ Immutability★ Uninterruptability ★ Controlled invocation

Att Process Config.★ 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

Our Approach - HYDRA★ Run Attestation Process (PRAtt) 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 (PRAtt) 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 PRAtt’s:○ 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 PR

2

Verifier sends an attestation request to PRAtt

PRAtt

performs att. and reports back to verifier

1

4

5

MM

I/O

RA

M/F

lash

RO

M

2

3

Verifier

1

2

3

4

5

20

Implementation➢ Prototype on I.MX6-SabreLite and Odroid-XU4

➢ Existing secure boot (High Assurance Boot - HAB) mechanism in Sabre Lite

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%

Performance 1/3

23

Performance 2/3

24

Performance 3/3

Lessons Learned

25

Challenges when using seL4Formal verification of seL4 assumes:

★ Proper initialization of the kernel○ Motivate using hardware-enforced secure boot

26

Challenges when using seL4Formal 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 + Signature

seL4 + Signature

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

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 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

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

KAttes

t

seL4 Kernel

PRAtt

Timer

Secure Boot

MM

I/O

RA

M/F

lash

RO

M

35

KAttes

t

seL4 Kernel

PRAtt

Timer

Secure Boot

MM

I/O

RA

M/F

lash

RO

M

T0

36

KAttes

t

seL4 Kernel

PRAtt

Timer

Secure Boot

MM

I/O

RA

M/F

lash

RO

M

T0

Verifier

@ T1

37

KAttes

t

seL4 Kernel

PRAtt

Timer

Secure Boot

MM

I/O

RA

M/F

lash

RO

M

T0

Verifier

T1

38

KAttes

t

seL4 Kernel

PRAtt

Timer

Secure Boot

MM

I/O

RA

M/F

lash

RO

M

T0

Verifier

T1

TS = T1 + Timer

39

Extras - ODROID experiments (for Wisec?)

40

41