SHIELDSTRAP: Making Secure Processors Truly Secure Siddhartha Chhabra, Brian Rogers, Yan Solihin Electrical and Computer Engineering North Carolina State

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


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


6

BIOS Section 2

Expansion ROMs

Primary Boot block

OS

Boot loader

A A A Steady state is secure

Boot process still mine


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


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


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


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)


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


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


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


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


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


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 }


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


20

SHIELDSTRAP: Architecture

Core ST-ROM

DL1$ IL1$

L2$

Crypto Engine

Secure Processor


21

Evaluation Security analysis Quantitative analysis


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


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


24

Security Analysis


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


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


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


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

expansion ROMS Detected as a verification failure in booting phase


Evaluation Security analysis Quantitative analysis


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)


31

Quantitative analysis: Performance Experimental setup


32

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

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


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


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


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


36

Questions ?


37

Thank you


38

Backup Slides…


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




TCB


40

Variant (Itoi et al.)

BIOS Section 2

Expansion ROMs Grub Stage 1

OS

BIOS Section 1


Grub Stage 2

Smart Card(MACs of kernel

and apps)

PIN based authentication

A A A




TCB


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


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


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.


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


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


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


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


Documents

SHIELDSTRAP: Making Secure Processors Truly Secure Siddhartha Chhabra, Brian Rogers, Yan Solihin Electrical and Computer Engineering North Carolina State