SHIELDSTRAP: Making Secure Processors Truly Secure Siddhartha Chhabra, Brian Rogers, Yan Solihin...

SHIELDSTRAP: Making Secure Processors Truly Secure

Siddhartha Chhabra, Brian Rogers, Yan Solihin

Electrical and Computer EngineeringNorth Carolina State University

ICCD-2009

2

Outline SHIELDSTRAP

Boot process in uniprocessors Need for secure booting Requirements of a Secure boot solution Previous work Assumed Attack Model SHIELDSTRAP Evaluation Conclusions

SHIELDSTRAP – ICCD 2009

3

Boot process in uniprocessors (PCs)

BIOSPOST (Power on Self Test)

Expansion ROMs

Boot Block

OS

BIOS forms the root of the booting process…..

BIOS

Boot loader

SHIELDSTRAP – ICCD 2009

Need for Secure Booting In addition to software attacks, hardware attacks

are emerging (e.g. Modchips) Software only protection vulnerable to hardware

attacks Secure Processor Architectures proposed to

defend against hardware attacks

4SHIELDSTRAP – ICCD 2009

5

Need for Secure Booting Most Secure processor architectures assume that the

system has booted up securely The bootstrap process is assumed to be a part of the Trusted

Computing Base (TCB)

Is it safe to assume that the system boots up securely

SHIELDSTRAP – ICCD 2009

6

BIOS Section 2

Expansion ROMs

Primary Boot block

OS

Boot loader

A A A Steady state is secure

Boot process still mine

SHIELDSTRAP – ICCD 2009

8

Modchips Gaming systems verify the signature of a game

DVD when inserted in the ROM The BIOS is responsible for performing these checks

A modchip is a hardware device with a BIOS that is an exact replica of the original BIOS minus the checks for enforcing DRM

SHIELDSTRAP – ICCD 2009

9

Modding attack

Original BIOS

Verify Digital signatures of the

DVD

If signature valid then

play the CDModChip

Play the DVD no verification

A major issue for the gaming industry, modchips available for all popular gaming systems (XBOX, XBOX360, PS2, PS3 Wii etc.)

SHIELDSTRAP – ICCD 2009

Need for Secure Booting Hence, it is not safe to assume that the system

has booted up securely Security of the system contingent on a secure

bootstrap of the system

10

Without Secure booting no integrity and confidentiality guarantees can be made

SHIELDSTRAP – ICCD 2009

Requirements of a secure boot solution

All boot components must be verified before passing control

The root of trust should be located on-chip TOCTTOU attacks prevention (Vulnerability

window attacks)

11SHIELDSTRAP – ICCD 2009

Previous Work

12

Low Cost High Cost

Lo

w S

ec

uri

tyH

igh

Se

cu

rity

AEGIS (Arbaugh

et al.)Aegis (Suh

et al.)

TCG, NGSCB, IBM Cell

BE

ARM TrustZoneSHIELDSTRAP

AEGIS (Arbaugh

et al.)Aegis (Suh

et al.)

TCG, NGSCB, IBM Cell

BE

ARM TrustZone

SHIELDSTRAP

SHIELDSTRAP – ICCD 2009

13

Attack model Everything on chip is secure: The processor core,

on-chip caches (L1, L2 and other caches introduced for the proposed scheme) Code and data cannot be observed/modified by the

attacker Everything outside the chip is non-secure: BIOS,

Memory bus, memory and the disk Code and data can be observed/modified by the attacker

Attacker has physical access to the system Software attacks on boot components equally likely

User/owner of the system can be the attacker

SHIELDSTRAP – ICCD 2009

14

SHIELDSTRAP in a nutshell We do not make assumptions about the integrity of off-

chip components We use an On-chip SHIELDSTRAP-ROM (ST-ROM) to

verify the boot components before starting the booting phase

The ST-ROM verifies the BIOS before passing control Once the BIOS is successfully verified the control is

passed to the BIOS which initiates the chained integrity verification phase where each component verifies the next one in the boot chain before passing control to it

SHIELDSTRAP – ICCD 2009

15

SHIELDSTRAP

BIOS

Expansion ROMsBoot Block

OS

ST-ROM

VERIFICATION PHASE (TOC)

Verify the BIOS before starting the boot process

Boot loader

BOOTING PHASE (TOU)

On successful verification of the BIOS. pass control to

BIOS to start the booting process

On-chip root of trust

SHIELDSTRAP – ICCD 2009

SHIELDSTRAP TOCTTOU attacks: The boot components come

under the protection of the secure processor mechanisms

However, processors can read the boot components directly Shadowing ROMs is made mandatory

16SHIELDSTRAP – ICCD 2009

17

ST-ROM SHIELDSTRAP ROM is an on-chip Read-only

memory and it stores the following A key to verify BIOS:

Public key of BIOS manufacturer Public key of Processor manufacturer Group signature scheme

An implementation of digital signature verification algorithms

We chose RSA-1024 and SHA-256 as RSA is faster for the verifier

ST-Code: Code responsible for carrying out the verification phase

Increasing Flexibility

SHIELDSTRAP – ICCD 2009

18

ST-Code //Verification Phase //Verify the BIOS biosSignature = read BIOS signature from BIOS; publicKeyBIOS = read public key from ST-ROM verified = verifySignature(BIOS, biosSignature, publicKeyBIOS) If(verified == false) { BOOT FAILURE } else { //Pass control to the BIOS to start the booting phase }

SHIELDSTRAP – ICCD 2009

Requirements of other boot comp. Each boot component stores the public key of

the next boot component: Limits flexibility Each boot component should be:

Signed by its manufacturer Include the public key signed by a Certificate

Authority Include the public key of the Certificate Authority

19SHIELDSTRAP – ICCD 2009

20

SHIELDSTRAP: Architecture

Core ST-ROM

DL1$ IL1$

L2$

Crypto Engine

Secure Processor

SHIELDSTRAP – ICCD 2009

21

Evaluation Security analysis Quantitative analysis

SHIELDSTRAP – ICCD 2009

22

Security analysis Case study 1: Pre-boot

attacks (e.g. Modchip attacks)

ST-ROM

Original BIOS

Verfication

Verification successful

Modchip

Signature mismatch, Boot

failure

Prevents against Modding attacks

SHIELDSTRAP – ICCD 2009

23

Security Analysis Case Study 2: TSOP Flashing

In older versions of Xbox systems, the BIOS was stored on a flashable chip called TSOP with write access disabled

Re-enabled the write access by soldering few points on the board

SHIELDSTRAP – ICCD 2009

24

Security Analysis

SHIELDSTRAP – ICCD 2009

25

Security Analysis SHIELDSTRAP defends against TSOP flashing

by detecting it in the verification phase (signature failure) and prevents the system from booting

Prevents against TSOP flashing attacks

SHIELDSTRAP – ICCD 2009

26

Security Analysis Case study 3: Possible TOCTTOU attack

SHIELDSTRAP verifies the boot components first and then passes control (vulnerability window)

ST-ROM

Verification

Verification OK

SHIELDSTRAP – ICCD 2009

27

Security Analysis HOWEVER, once the boot component is loaded

to memory for verification, it comes under the protection of the Merkle tree along with the other dynamic data produced by ST-Code and cannot be modified by the attacker without detection

NO TOCTTOU Attacks possible

SHIELDSTRAP – ICCD 2009

Security Analysis Case study 4: Software attacks e.g. rootkits in MBR and

expansion ROMS Detected as a verification failure in booting phase

28SHIELDSTRAP – ICCD 2009

Evaluation Security analysis Quantitative analysis

29SHIELDSTRAP – ICCD 2009

Quantitative Analysis: Area Area overhead

Cryptographic algorithms Public key for signature verification ST-Code

Total area required: ~13KB

Area estimate: 0.017 mm2 (0.012% overhead for a

pentium 4 processor)

30SHIELDSTRAP – ICCD 2009

31

Quantitative analysis: Performance Experimental setup

SHIELDSTRAP – ICCD 2009

32

Quantitative analysis: Performance The cryptographic operations in the boot process are

modeled using an open source cryptographic library (Crypto++)

SHIELDSTRAP – ICCD 2009

Quantitative analysis: Performance SHIELDSTRAP adds 0.37 seconds to the boot

process (measured on a real system) 0.8% overhead on the modeled secure

processor OS comprises upto 80% of the overhead

Further reduced overheads for specialized systems (gaming and embedded) employing reduced kernels

33SHIELDSTRAP – ICCD 2009

34

Conclusions

BIOS Section 2

Expansion ROMs

Primary Boot block

OS

Boot loader

A A A Steady state is secure

Boot process still mine

Boot up is secure as well

+

Truly secure processor

SHIELDSTRAP

SHIELDSTRAP – ICCD 2009

Conclusions SHIELDSTRAP: Secure bootstrap mechanism

Bridges the gap between the vulnerable initialization and steady state operation of a secure processor

Security: Defends against hardware and software attacks

Low complexity: Lightweight additions to the processor in terms of area and performance

Flexibility: Allows for hardware and software re-configuration

35SHIELDSTRAP – ICCD 2009

36

Questions ?

SHIELDSTRAP – ICCD 2009

37

Thank you

SHIELDSTRAP – ICCD 2009

38

Backup Slides…

SHIELDSTRAP – ICCD 2009

39

AEGIS (Arbaugh et al.)

BIOS Section 2

Expansion ROMs

Boot Block(s)

OS

BIOS Section 1AEGIS ROM

Network host

Compute Hash and verify signature

Compute Hash and verify signature

Compute Hash and verify signature

Compute Hash and verify signature

TCB

SHIELDSTRAP – ICCD 2009

40

Variant (Itoi et al.)

BIOS Section 2

Expansion ROMs Grub Stage 1

OS

BIOS Section 1

Compute Hash and verify signature

Grub Stage 2

Smart Card(MACs of kernel

and apps)

PIN based authentication

A A A

Compute Hash and verify signature

Compute Hash and verify signature

Compute Hash and verify signature

TCB

SHIELDSTRAP – ICCD 2009

41

Trusted computing group approach

BIOS

Expansion ROMs

Primary Boot block

Secondary boot block

Operating system(Device drivers, application etc.)

PCR[1]

PCR[0]

PCR[14]

PCR[13]

PCR[12]

PCR[11]

PCR[10]

PCR[9]

PCR[8]

PCR[7]

PCR[6]

PCR[5]

PCR[4]

PCR[3]

PCR[2]

HardwareConf.

Events

Reserved

Prone to attacks

Assumed TCB

BIOS Boot Block(TCB)

BIOS

Microsoft proposed palladium which follows a similar

approach and both schemes require non-trivial hardware

changes and additions

Remote Attestation

SHIELDSTRAP – ICCD 2009

42

Arbaugh et. al. Does not prevent against hardware attacks: e.g.

Modding attack A BIOS upgrade will cause the system to bypass

the secure booting mechanism as the BIOS forms the root of trust

The keys for verifying the boot components are stores in the BIOS or the AEGIS ROM. Ties the system configuration (hardware and

software) to the booting mechanism i.e. any changes to the system configuration cause a boot

failure

SHIELDSTRAP – ICCD 2009

43

TCG and Palladium It does allow for BIOS upgrades as the root of trust is

part of the BIOS that does not change on upgrades (BIOS boot block)

Hardware attacks: Does not prevent against hardware attacks (e.g. Modding attack)

Requires non-trivial changes to the current hardware and addition of a Trusted Platform module, which is essentially a secure co-processor

These are Optional for the user, hence the attacks we discussed can still be easily carried out by the user by simply turning these features off.

SHIELDSTRAP – ICCD 2009

44

ST-Code VerifySignature(component, signature, publicKey) { verificationBlock = read first 512 bits from the component; runningHash = hash(verificationBlock); While(!endOfComponent) { verificationBlock = read next 512 bits from the component; runningHash = updateHash(runningHash, verificationBlock); } expectedHash = obtain expected hash from the signature using the publicKey if(expectedHash == runningHash) { return true } else { return false; } }

SHIELDSTRAP – ICCD 2009

45

Quantitative analysis: ST overhead

0.996

0.998

1

1.002

1.004

1.006

1.008

1.01

AEGIS SHIELDTRAP SHIELDTRAP+SECUREPROC

No

rmal

ized

ove

rhea

d

Adds 0.48 seconds to the boot process over a base machine with no security

SHIELDSTRAP – ICCD 2009

46

Quantitative analysis: ST Miss rates

0.53%

0.53%

0.54%

0.54%

0.55%

0.55%

0.56%

0.56%

0.57%

AEGIS SHIELDTRAP SHIELDTRAP+SECUREPROC

L2

Mis

s R

ate

Verification phase added is compute intensive and does not incur many misses other than the cold misses, hence secure processor

with the software implementation does not add any significant overhead

SHIELDSTRAP – ICCD 2009

47

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

BIOS ExpansionROMs BootBlock BootLoader OS

Ex

ec

uti

on t

ime

ov

erh

ea

d f

or

bo

ot

co

mp

on

en

ts

The OS being the largest component contributes around 80% of the overhead, we have assumed a linux kernel, specialized kernels will

be smaller in size and can therefore reduce the already insignificant overhead

SHIELDSTRAP – ICCD 2009