December 3 - 6, 2018Santa Clara Convention CenterCA, USA

REVOLUTIONIZING THE COMPUTING LANDSCAPE AND BEYOND.https://tmt.knect365.com/risc-v-summit @risc_v

Ilia LebedevGraduate StudentMassachusetts Institute of Technology

SECURE BOOTSTRAPPING OF TRUSTED SOFTWARE IN RISC-V

https://tmt.knect365.com/risc-v-summit @risc_v

Secure Bootstrapping of Trusted Software in RISC-V

Ilia Lebedev, Kyle Hogan, Jules Drean, Srini Devadas - MIT

This work was partially funded by Delta Electronics, Analog Devices,DARPA & SPAWAR (N66001-15-C-4066), and DARPA SSITH (HR001118C0018).

We often have no ideawhether trust is justified

4

(?•_•)

Hi, are youSteve?

୧༼ ಠ益ಠ ༽୨

Trusted first party A suspicious system

Ok, sure, I’m Skeeve. Steeve? Steve.

I don’t know if I can trust you :’(

I expect a specific software environment that I trust;

I call it Steve.

5

?

?

??

? ??

?

?

?? (☞ﾟヮﾟ)☞

??

?

?

Oh hi! I am Steve and I am securely loaded ontrusted hardware

+

( this talk lives here )

I also trust the manufacturer of

this hardware

I trust a binary, which I call Steve

Untrusted environment,software adversary

- https://medium.com/@ilia.lebedev/secure-boot-2d6e319b6978 - https://eprint.iacr.org/2018/427

Secure Bootstrapping of Trusted Software in RISC-V

https://medium.com/@ilia.lebedev/secure-boot-2d6e319b6978https://eprint.iacr.org/2018/427

6

Consider trust: actors in a system (1/2)

How is each trusted?What specific guarantees can be made?

anonymous remote users

ヽ(• ́o• ̀)ノ Authenticated remote users

Post-boot software (inc. third party

modules)

user-provided software (scripts in a

web page)

Users with physical access

HardwareRoot of trust

software

7

Consider trust: actors in a system (2/2)

anonymous remote users

ヽ(• ́o• ̀)ノ Authenticated remote users

Post-boot software (inc. third party

modules)

user-provided software (scripts in a

web page)

Users with physical access

Root of trustsoftware

Hardware

Guarantee integrity for loading a boot image in an untrusted setting, given pre-existing trust in HW, manufacturer, desired boot image

(no special protection from

denial of service)

(no protection)

Threat ModelUnconditional trust:

- Manufacturer’s keys, trusted HW- Desired boot image (key privacy)- … and you! (the first party)

Adversary: boot a different, malicious binary, interact with it

… but not tamper with the the hardware

… or extract its secret key

… or deny service8

1: M is a trustworthy CA

9

Publish PKM{SKM, PKM}ed25519

cryptosystem*

ManufacturerCertificate Authority

Manufacturer securely generates and stores SKM

*RSA is also a reasonable choice

We will document our chain of trust here:

2: M builds a trustworthy D with keys

10

Publish PKM{SKM, PKM}

{SKD*, PKD}

D has some properties:

- Trustworthy keys- No back doors- A trusted ROM- First instruction integrity

*D exposes SKD via a special interface,and is hidden from normal software.

Manufacturer

Processor D

Certificate Authority

3: M certifies PKD

11

Publish PKM{SKM, PKM}

PKD

Sign(PKD, SKM) Publish M’s endorsement of PKD: CertD

Manufacturer

Processor D

Certificate Authority

Proves* that a device with access to SK

D

is D manufactured by M.

*trust assumptions...

4: D executes from a root of trust at resetD must guarantee first instruction integrity

1). Erase (or re-key) memory

… secrets from previous boot

erasing GBs of DRAM is very slow!

2). Load an untrusted binary

… assuming it has certain structure

(size, reserved space for keys, etc.)

12

DRAMUntrusted

boot image

0x80..000

¯\_(ツ)_/¯

TrustedROM

0x1000

Root of trust

(clean)

0x80..000

0x1000

stack

reserved space

size

S

Root of trust

5: Root of trust measures S→HS

13

Manufacturer

Processor D

Software S

Certificate Authority

(clean)

0x80..000

0x1000

SHA3

size

(clean)

0x80..000

0x1000

S S

Root of trust

Root of trust

HS

S

stack

sizeof(S)

HS

PKDPKM

1024B

8B

32B

32B

32B

64B

64B

64B

64B

Hash the binary S in memory → H

S

Note: can shrink the ROM by hashing and verifying the bootloader in RAM

6: Root of trust endows S with unique keys

14

Manufacturer

Processor D

Software S

Certificate Authority

*D has access to SKD

, puts it on the stack.

0x80..000

0x1000

HS

0x80..000

0x1000

KDF

SKD

S

stack

sizeof(S)

HS

PKS

SKS

certDPKDPKM

1024B

8B

32B

32B

32B

64B

64B

64B

64B *

(clean) (clean)

S S

Root of trust

Root of trust

{SKS ,PKS}

KDF({HS,

SKD

}) → {SKS ,PKS}

Note: can store encrypted SKS in public, use SHA3(SK

D) to encrypt/decrypt

7: Root of trust certifies {HS,PKS}

15

Manufacturer

Processor D

Software S

Certificate Authority

0x80..000

0x1000

0x80..000

0x1000

1024B

8B

32B

32B

32B

64B

64B

64B

64B

(clean) (clean)

S S

Root of trust

Root of trust

S

sizeof(S)certSHS

PKS

SKS

certDPKDPKM

stack

{HS,PKS}

SKD*

certSSign

*SKD

is on the stack.

Sign({HS,

PKS}, SK

D) → certS

8: Root of trust cleans up and boots S

16

0x80..000

0x1000

0x80..000

0x1000

(clean)erase

Root of trust

Root of trust

Manufacturer

Processor D

Software S

Certificate Authority

S

stack

sizeof(S)certSHS

PKS

SKS

certDPKDPKM

1024B

8B

32B

32B

32B

64B

64B

64B

64B

Secrets are on the stack

.. and in μarchitecture

.. and SKD must be hidden (clean) (clean)

S S

9: S performs attestation (1/4)

17

S on D, trusted to maintain secrecy of SKS

Trusted first party

… has a prioritrust in PKM

(⇀_⇀)

Hi, are youSteve?

☜(ﾟヮﾟ☜)

Trusted first party S on D

Yes! Here is a fresh proof that I am Steve

running on device built by

Ok, thanks

9: S performs attestation (2/4)

18

(ಠ ∩ಠ)

Hi, are youSteve?

¯\_(ツ)_/¯

Adversary S on D

Yes! Here is a fresh proof that I am Steve

running on device built by

Ok, thanks

(╭☞'ω')╭☞

Hi, are youSteve?

Trusted first party

Yes! Here is a fresh proof that I am Steve

running on device built by

Ok, thanks

An attestation only proves the sender has access to

a genuine system.

A man-in-the-middle adversary (even a local one) may pass

attestation

9: S performs attestation (3/4)

19

S on D, trusted to maintain secrecy of SKS

Trusted first party

Other key agreement protocols exit too

(e.g. Diffie Hellman)

Key agreement to defeat a man-in-middle; encrypt

attestation with Kand include K in the attestation

The adversary cannot compute K

We did it!

20

Read the Medium article for extensions to this boot protocol to make it more flexible

( ￣ー￣)σ

Hi, are youSteve?

ヾ(・ω・ｏ)

Trusted first party S on D

Yes! Here is a fresh proof computed by me that I am Steve running on device

built by

Ok, thanks

https://medium.com/@ilia.lebedev/secure-boot-2d6e319b6978

Booting with Multiple Harts

21

Core 0

Corenot 0

time

0x1000

0x1000

yeah!

do bootloader things

Send IPI to cores

+20 ASM instructions

Enable IPI WFI

Boot address

Boot address

no :(

Is this core 0?

Is this core 0?

+7 ASM instructions

(barrier via interrupts)

Trust S w/o 1st party: gatekeeping (1/2)

22

IDEA 1: White-list the allowed S in the root of trust. The space of software that

can boot with an integrity guarantee from the RoT is pre-defined and immutable

Trust S w/o 1st party: gatekeeping (2/2)

23

IDEA 2: Delegate white-listing of S to a certificate.

If a small TCB is the goal...

24

AES403 LOC

- U-BOOT: ~2,000,000 LOC- GRUB: ~326,000 LOC- GRUB Legacy: ~43,000 LOC

ed25519 KDF3868 LOC

SHA3138 LOC

root of trust204 LOC

ASM 116 LOCC 88 LOC

~4,600 LOC

Not judging, but feature-packed bootloaders are huge:

The things we’ve swept under the rug...- How can we trust S is keep SK

S secret?

- Where does SKD

come from, exactly?

- What is our trust in the Manufacturer?

25PUF-backed keys

Sanctum/Keystone, or at least a PMP rule

THANKYOUhttps://tmt.knect365.com/risc-v-summit @risc_v