Transcript Document

SHIELDSTRAP:A Secure
Bootstrap Architecture
Siddhartha Chhabra and Yan Solihin
Electrical and Computer Engineering
North Carolina State University
WIOSCA-2009
Outline

SHIELDSTRAP
 Boot
process in uniprocessors
 Need for secure booting
 Requirements of a Secure boot solution
 Previous work
 Assumed Attack Model
 SHIELDSTRAP
 Evaluation
 Conclusions
Chhabra, Solihin - Secure Boot
2
Boot process in uniprocessors (PCs)
OS
Boot loader
Boot Block
Expansion ROMs
POSTBIOS
(Power on
Self Test)
BIOS forms the root of the booting process…..
Chhabra, Solihin - Secure Boot
3
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
Chhabra, Solihin - Secure Boot
4
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
Chhabra, Solihin - Secure Boot
5
A
A
A
Steady state is
secure
OS
Boot process still mine
Boot loader
Primary Boot block
Expansion ROMs
BIOS Section 2
Chhabra, Solihin - Secure Boot
6
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
Chhabra, Solihin - Secure Boot
8
Modding attack
Play
Verify
theDigital
DVD no
signatures
verification
of the
DVD
If signature
valid then
play the CD
Original BIOS
ModChip
A major issue for the gaming industry, modchips available for all popular
gaming systems (XBOX, XBOX360, PS2, PS3 Wii etc.)
Chhabra, Solihin - Secure Boot
9
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
Without Secure booting no integrity and confidentiality guarantees can
be made
Chhabra, Solihin - Secure Boot
10
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)
Chhabra, Solihin - Secure Boot
11
High Security
Previous Work
SHIELDSTRAP
ARM
TrustZone
Low Security
AEGIS
TCG,
ARM
TrustZone
(Arbaugh
NGSCB,
SHIELDSTRAP
IBM
et al.)
Cell
Aegis
BE(Suh
et al.)
AEGIS
(Arbaugh
et al.)
Aegis (Suh
et al.)
TCG,
NGSCB,
IBM Cell
BE
Low Cost
High Cost
Chhabra, Solihin - Secure Boot
12
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
User/owner of the system can be 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
Chhabra, Solihin - Secure Boot
13
SHIELDTRAP in a nutshell




We do not make assumptions about the integrity of offchip components
We use an On-chip SHIELDTRAP-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
Chhabra, Solihin - Secure Boot
14
SHIELDTRAP
OS
BOOTING
PHASE
VERIFICATION
(TOU)
PHASE
(TOC)
Boot loader
On
successful
verification
Verify
the BIOS
before
of
the
BIOS.
pass
control to
starting the boot process
BIOS to start the booting
process
Expansion ROMs
Boot Block
BIOS
ST-ROM
On-chip root of trust
Chhabra, Solihin - Secure Boot
15
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
Chhabra, Solihin - Secure Boot
16
ST-ROM

SHIELDTRAP 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
Increasing
Flexibility
 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
Chhabra, Solihin - Secure Boot
17
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
}
Chhabra, Solihin - Secure Boot
18
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
Chhabra, Solihin - Secure Boot
19
SHIELDTRAP: Architecture
Secure Processor
Core
ST-ROM
IL1$
DL1$
L2$
Crypto
Engine
Chhabra, Solihin - Secure Boot
20
Evaluation


Security analysis
Quantitative analysis
Chhabra, Solihin - Secure Boot
21
Security analysis

Case study 1: Pre-boot
attacks (e.g. Modchip
attacks)
Prevents against
Modding attacks
ST-ROM
Signature
Verification
mismatch, Boot
successful
failure
Verfication
Original
Modchip
BIOS
Chhabra, Solihin - Secure Boot
22
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
Chhabra, Solihin - Secure Boot
23
Security Analysis
Chhabra, Solihin - Secure Boot
24
Security Analysis

SHIELDTRAP defends against TSOP flashing
by detecting it in the verification phase
(signature failure) and prevents the system from
booting
Prevents against TSOP
flashing attacks
Chhabra, Solihin - Secure Boot
25
Security Analysis

Case study 3: Possible TOCTTOU attack

SHIELDTRAP verifies the boot components first and then
passes control (vulnerability window)
ST-ROM
Verification OK
Verification
Chhabra, Solihin - Secure Boot
26
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
Chhabra, Solihin - Secure Boot
27
Security Analysis

Case study 4: Software attacks e.g. rootkits in MBR and
expansion ROMS

Detected as a verification failure in booting phase
Chhabra, Solihin - Secure Boot
28
Evaluation


Security analysis
Quantitative analysis
Chhabra, Solihin - Secure Boot
29
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)
Chhabra, Solihin - Secure Boot
30
Quantitative analysis: Performance

Experimental setup
Chhabra, Solihin - Secure Boot
31
Quantitative analysis: Performance

The cryptographic operations in the boot process are
modeled using an open source cryptographic library
(Crypto++)
Chhabra, Solihin - Secure Boot
32
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
Chhabra, Solihin - Secure Boot
33
Conclusions
A
A
A
Steady state is
secure
OS
+
Boot process still mine
Boot loader
SHIELDTRAP
Boot up is secure
as well
Primary Boot block
Expansion ROMs
Truly secure
processor
BIOS Section 2
Chhabra, Solihin - Secure Boot
34
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 reconfiguration
Chhabra, Solihin - Secure Boot
35
Questions ?
Chhabra, Solihin - Secure Boot
36
Thank you
Chhabra, Solihin - Secure Boot
37
Backup Slides…
Chhabra, Solihin - Secure Boot
38
AEGIS (Arbaugh et al.)
OS
Compute Hash and
verify signature
Network host
Boot Block(s)
Compute Hash and
verify signature
Expansion ROMs
Compute Hash and
verify signature
BIOS Section 2
Compute Hash and
verify signature
AEGIS ROM
BIOS Section 1
TCB
Chhabra, Solihin - Secure Boot
39
Variant (Itoi et al.)
A
A
A
PIN based
authentication
OS
Smart Card
(MACs of kernel
and apps)
Grub Stage 2
Compute Hash and
verify signature
Expansion ROMs
Grub Stage 1
Compute Hash and
verify signature
Compute Hash and
verify signature
BIOS Section 2
Compute Hash and
verify signature
BIOS Section 1
TCB
Chhabra, Solihin - Secure Boot
40
Trusted computing group approach
Operating system
(Device drivers,
application etc.)
PCR[14]
PCR[13]
Secondary boot block
PCR[12]
PCR[11]
Remote
Attestation
PCR[10]
PCR[9]
Primary Boot block
PCR[8]
Expansion ROMs
PCR[7]
Reserved
PCR[6]
Events
PCR[5]
PCR[4]
PCR[3]
BIOS
PCR[2]
BIOS
Microsoft proposed palladium
which follows a similar
approach and both schemes
require non-trivial hardware
changes and additions
PCR[1]
Hardware
Conf.
PCR[0]
BIOS Boot
Block
(TCB)
Prone to attacks
Assumed TCB
Chhabra, Solihin - Secure Boot
41
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
Chhabra, Solihin - Secure Boot
42
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.
Chhabra, Solihin - Secure Boot
43
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;
}
}
Chhabra, Solihin - Secure Boot
44
Quantitative analysis: ST overhead
1.01
Normalized overhead
1.008
1.006
1.004
1.002
1
0.998
0.996
AEGIS
SHIELDTRAP
SHIELDTRAP+SECUREPROC
Adds 0.48 seconds to the boot process over a base
machine with no security
Chhabra, Solihin - Secure Boot
45
Quantitative analysis: ST Miss rates
0.57%
0.56%
L2 Miss Rate
0.56%
0.55%
0.55%
0.54%
0.54%
0.53%
0.53%
AEGIS
SHIELDTRAP
SHIELDTRAP+SECUREPROC
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
Chhabra, Solihin - Secure Boot
46
Execution time overhead for boot
components
90.00%
80.00%
70.00%
60.00%
50.00%
40.00%
30.00%
20.00%
10.00%
0.00%
BIOS
ExpansionROMs
BootBlock
BootLoader
OS
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
Chhabra, Solihin - Secure Boot
47