Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
IBM Research
1©2007 IBM Corporation
Trustworthy Hardware
Trustworthy Hardware
Trustworthy Hardware
Trustworthy Hardware
Pankaj Rohatgi
Pankaj Rohatgi
Pankaj Rohatgi
Pankaj Rohatgi
IBM T. J. Watson Research Center
IBM T. J. Watson Research Center
IBM T. J. Watson Research Center
IBM T. J. Watson Research Center
CHES 2007
CHES 2007
CHES 2007
CHES 2007
IBM Research
2©2007 IBM Corporation
Acknowledgements
�IBM 4758 team in IBM Research/Development
�IBM Research
–Caernarvonsmart-card OS team
–Zurich Research Lab: JavaCardteam.
–Secure Blue team
–Secure Hypervisor (sHype) and Virtual TPM (vTPM) team
–System S team
–Colleagues: DakshiAgrawal, StefanBerger, Suresh Chari, Leendert
van Doorn, Eric Hall, CharanjitJutla, Paul Karger, Elaine Palmer, Reiner
Sailer, Helmut Scherzer, Sean Smith,, Ronald Perez, J. R. Rao, Steve
Weingart.
�IBM’s Internet Security Systems Division
�Prof BerkSunarand his students: Denizand Selcuk
�CHES community.
IBM Research
3©2007 IBM Corporation
FOR MOST SYSTEMS
•Few sophisticated
users and developers
•Few applications, interfaces,
data flows.
•Few sophisticated malevolent
attackers
•Script kiddies, publicity
seekers
•Long application development
and testing cycles
•Firewalls, anti-virus, secure
communications considered
good enough !
Adapted from IBM Internet Security Systems
Inform
ation Security: Once upon a time ...
FEW SPECIALIZED SYSTEMS REQURING VERY HIGH SOFTWARE/HW SECURITY
•Secure OS/DBMS (Defense), Secure embedded devices with cryptographic capability,
and tamper-resistance, but limited functionality (Defense, Banking, PayTV)
•Adversarial models, requirements, scenarios and techniques developed in these
contexts considered esoteric and non-mainstream.
IBM Research
4©2007 IBM Corporation
Inform
ation (In)Security–now
IBM Research
5©2007 IBM Corporation
Many forms
of valuable data
�Structured
�Unstructured
�Images
�Video, Voice
All of which are
subject to increasingly
sophisticated internal
and external attacks
or
accidental leakage !
Accessible from/stored
in multiple ways and
on multiple
devices…
�Cell phones
�Laptops
�PDAs,iPods
�Briefcases
Business
Partners
Supply
Chain
Coffee Shop
Hotels
Home
Information Security: Enterprise Perspective
Adapted from: IBM Internet Security Systems
IBM Research
6©2007 IBM Corporation
Source: IBM Internet Security Systems: http://www.iss.net/evolvingthreat/
Internet Threats: The New Reality
IBM Research
7©2007 IBM Corporation
Software (In)securityTrends
20002001
20022004
2005
2006
0
1000
2000
3000
4000
5000
6000
7000
8000
Software Vulnerabilities Reported
23% CAGR
6415
6415
6415
6415
21805
21805
21805
21805
26829
26829
26829
26829
28444
28444
28444
28444
32474
32474
32474
32474
38746
38746
38746
38746
39169
39169
39169
39169
49679
49679
49679
49679
68620
68620
68620
68620
KeyLogger
Virus
Misc
PWD Steal
Dialer
Backdoor
Worm
Trojan
Downloader
IBM/ISS analysis of the 2006
IBM/ISS analysis of the 2006 malware
malwareZoo
Zoo
Percentage of Remotely Exploitable Vulnerabilities
Percentage of Remotely Exploitable Vulnerabilities
Percentage of Remotely Exploitable Vulnerabilities
Percentage of Remotely Exploitable Vulnerabilities
0
10
20
30
40
50
60
70
80
90
100
2000
2001
2002
2003
2004
2005
2006
Impact of 2006 Vulnerabilies
50%
15%
11%
10%
5%
4%
2%2%1%
Gain Access
Data Manipulation
DoS
Obtain Info
Bypass Sec
Gain Privilege
Inform
ational
File Manipulatio
Other
IBM Research
8©2007 IBM Corporation
Systems, applications and attack scenarios once
considered “niche”and “esoteric”are now mainstream !
-Security lessons from those systems now applicable
IBM Research
9©2007 IBM Corporation
Attackers quickly follow the value –Mobile Platforms Case Study
2006 Worldwide Sales of Mobile Phones
2694
135
209
957
0
500
1000
Game
Consoles
Digital
Cameras
Music
Players
Personal
Computers
Mobile
Phones
Source: Apple Inc.
Millions of Units
•Mobile technology marketplace is
large and growing fast
•Mobile phones poised to become
the dominant personal computing
platform (e.g., billions of phones
already deployed)
•Mobile phones rapidly gaining
capabilities and increasingly exhibit
the security vulnerabilities of full-
sized computers.
•Cross-platform runtime
environments are facilitating the
development of rich Web apps on
mobile phones
“By 2009, 70% of knowledge work will occur in
locations where workers depend on wireless and
remote-access infrastructure outside the enterprise's
direct control.”Gartner
“Mobility has become a critical component of the IT
and communications fabric for businesses of all
sizes.”Forrester
“Mobility remains a high-priority CIO issue that will
drive steady growth in demand for mobile products
and services for several years.”Gartner
“Organizations that adopt mobile solutions…will
reap significant economic benefit.”BCG
IBM Research
10
©2007 IBM Corporation
Threats to Mobile platforms
•More than 370 mobile phone viruses so far
•Tens of thousands of infections worldwide
•Cabirand Commwarriorreports from > 30 countries
•Operator with 9 million customers: almost 5% of
MMS traffic infected
•Operator with 14 million customers: Over 8000
infected devices have sent over 450000 MMS
messages. Largest number of messages sent by one
phone: 3500.
•Operators have given money back to customers who
had Commwarrior
Primary threat: Loss of devices (PCs + Mobile) with
sensitive enterprise data:
•# of laptops stolen in US in 2005: 750,000 –97% never
recovered –(est., Absolute Software).
•Over 6 months in London riders left behind 4,973 laptops;
5,939 Pocket PCs; and 63,135 mobile phones (source:
Pointsec+ Taxi Drivers Assoc.)
Malware: Whatsbeen seen so far
•Viruses and Worms: 58; Trojans: 297; Spy tools: 9;
Whatsnot been seen yet
•Rootkits
•Worms that do not need user interaction for spreading
•Mobile botnets
•Large-scale profit-oriented malware(professionals)
Source: F-Secure
IBM Research
11
©2007 IBM Corporation
So what’s being done now about Inform
ation Insecurity ?
IBM Research
12
©2007 IBM Corporation
Better Security using Hardware !
This is a great time to be part of the
CHES community !
IBM Research
13
©2007 IBM Corporation
Better Security Using Hardware: What’s mainstream
External Hardware-Assisted Appliances “chaperone” insecure software/systems
INTERNET
INTERNET
INTERNAL NETWORK
INTERNAL NETWORK
Web-servers, SMTP
Firewall
Email Filter/
Anti-Spam
Anti-virus.
Virus Protection System.
Web Application Firewall
Information Leakage Protection.
Intrusion Detection System (IDS)
Intrusion Prevention System (IPS)
NAC
......
IDS/IPS.
System Mgmt
& compliance.
DMZ
+ Crypto: Acceleration, Secure
Communication, Key Mgmt,
SSO/Authentication
+ SSL/IPSEC VPN
SOA/XML/WS-Security
SSO
+ Disk/TAPE Encryption
IBM Research
14
©2007 IBM Corporation
Mainstream: General purpose CPUs with Crypto Acceleration
�Sun Niagara 2: 8 cores
–2 pipelines, 4 threads, 1 FP and 1 crypto unit per core
–Support for DES/3DES, AES. RC4, SHA1, SHA256, MD5,
RSA 2048, ECC.
�IBM z-series mainframe
–Crypto Assist (CP Assist) per central processor CP
•DES/3DES (encryption/mac), SHA1
–2 CMOS secure crypto co-processors/machine
•FIPS 140-2 Level 4
IBM Research
15
©2007 IBM Corporation
What’s is becoming mainstream: Trusted computing
�TCG/TPM
–Core Root of Trust
–Trusted Boot
–Integrity Measurement
Architecture
–Remote Attestation
–Secure Key Storage
Analysis
System-Representation
SHA1(Boot Process)
SHA1(Kernel)
SHA1(Kernel Modules)
SHA1(Program)
SHA1(Libraries)
SHA1(Configurations)
SHA1(Structured data)
…
Measurement
System Properties
ext. Information
(CERT,…)
Known Fingerprints
Attested System
Program
Kernel
Kernel module
Config data
Boot Process
Data
TPM-Signed
PCR Integrity Value
Physical security of TPM
Measurement
Flow
Defined by TCG
(Platform specific)
Platform Configuration Registers 0-23
0-7
Defined by Grub
(IBM Tokyo Research Lab)
4-7
TCG-based
Integrity Measurement Architecture
>= 8
Execution
Flow
IBM ESS
Integrity Measurement Architecture extended to OS/Applications
IBM Research
16
©2007 IBM Corporation
IBM 4758
�Programmable crypto (DES/3DES/SHA1/DSA/RSA/RNG) co-processor
�World’s first programmable crypto co-coprocessor to obtain FIPS 140-1 Level 4
certification for Physical and Logical security of Hardware and Firmware.
�SEVERAL INNOVATIONS
–Secure Key Storage protected by a tamper detection and response mechanism certified to FIPS
140-1/2 Level 4.
–Secure Boot. Field upgradable(including part of firmware)
–Remote Attestation (outbound authentication)
–Programming Model based on a Layered Trust Model
BLOCK DIAGRAM
IBM Research
17
©2007 IBM Corporation
4758 Layered Trust Model for Code
�Initial OS/App
–CPQ++/CCA
�IBM to certify key of
Segment 2 owner
–Segment 2 owner
manages/loads
Segment 3 Apps
–Could also relinquish
ownership (and lose
segment 2 keys)
FIPS
CERTIFIED
FLASH ACCESS MODEL
IBM Research
18
©2007 IBM Corporation
What’s becoming mainstream: Support for “Secure”Virtualization
�Secure Virtualization, Secure Execution
Environment (Dynamic Root of Trust),
Remote Mgmt
–Supported by Intel VPRO& AMD Pacifica
–Enable significant security capabilities
Hardware: x86
COTS OS #1
App 3
UntrustedGuest
Partition 1
COTS OS #2
App 2
UntrustedGuest
Partition 2
“Trustworthy”
OS
Trusted Partition
protected from
other guests
App 1
App 2
App 1
“Secure”Hypervisor“T
rustworthy”
OS
Protected System Partition
for Resource Management
and Security Services
Protected
Intrusion
Detection
And
Response
vTPM
TGG based
measurements
and trusted
VM bootstrap
VM
Resource
Control
REMOTE
MGMT
IBM Research
19
©2007 IBM Corporation
What’s considered “niche”now
�Several application domains require usable and affordable
hardware/software devices with high physical and logical
security and have unique threat models
–Sensors and Actuators
•Critical infrastructure control (SCADA).
•Battlefield sensors, smart-dust.
–Trustworthy Defense Infrastructure
•Securing systems
•Systems that are free from Trojans (huge emerging problem).
–Gaming Consoles
•E.g., Xbox 360, PS3, Wii
–Content Protection/DRM
•Video/Audio: e.g., HD-DVD, Blue-ray...
•PayTV
–Handheld/Mobile devices
•Protection from malwareand device loss
–RFID Tags
–IDs and ePassports.....
IBM Research
20
©2007 IBM Corporation
Secure Processors
�Examples
–Secure Blue (IBM)
–XOM (Toronto)
–Princeton (PALMS) secure processor effort.
–AEGIS (MIT)
�Secure Blue Architecture
–Tamper-Resistant IC
–Encrypted external
memory
–Affordable
–Operates at full
processor speed
–Secure Key Mgmt
for confidentiality
–Secure Boot,
–Secure firmware
updates
Chip
Bou
ndary
Pro
cess
or
Oth
er
Mast
ers
Mast
er K
ey
Boot
Rec
ord
S/W
Rec
ord
Sec
ure
Bri
dge
Tam
per
Det
ect
an
d R
esponse
Oth
er
Mast
ers
Exte
rnal
Bus
Contr
oll
er
Mem
ory
Contr
oll
er
Host
Bus
Bri
dge
SD
RA
M
FL
AS
H
Acc
ess
Contr
ol
Met
a-D
ata
Cache/
SR
AM
Cry
pto
Engin
e
Key
/Zone
Table
s
HW
RN
G
Encryption, Integrity
Replay Protection
IBM Research
21
©2007 IBM Corporation
Predictions
�Applications and threats considered to be “niche” and
“esoteric” today will become commonplace in the years to
come.
�Huge challenges will need to be overcome
�Success will depend on new technology that aligns with
business imperatives, trends and constraints
–Truly innovative solutions will convert what appear to be inherent
disadvantages and problems into an advantage.
�Techniques and lessons learnt in tackling these challenges will
have lasting value.
�Ideal topics for those starting their research career in this area !
IBM Research
22
©2007 IBM Corporation
Building a usable and affordable hardware/software device
with high level of physical and logical security
�Several challenges, many unsolved problems, many
exciting opportunities
�Need to consider the complete lifecycle of the device
–Design
–Build/Test
–Deploy
–Maintain
–Decommissioning
�Several new challenges, requirements and attack
scenarios at each stage of the lifecycle.
IBM Research
23
©2007 IBM Corporation
Decommissioning
�Must design in the ability to efficiently migrate to a new device.
–Applications can live much longer than the device.
–Virtual machines/environments require rapid decommissioning of
virtualized devices (vTPM).
�Dealing with Data Reminiscence
–Very hard to delete all data through software.
•Some data never gets deleted (e.g., bad sector)
•Information physically available after “overwrite” [Gutman]
–Encrypt Data and Delete (Purge) Keys to erase
•Purging Keys: Reminiscence and Imprinting problem
•In the 4758
–Radiation sensors
–Temperature sensors
–Effects of time.
»“screensaver” for keys, periodic scrambling of contents
–High security systems: Many places for malicious software to hide
information: e.g., device flash/e2prom
•“Virtual” access to untrustedsoftware may be the only solution.
IBM Research
24
©2007 IBM Corporation
Maintenance
�Upgrades: planned and unplanned
–Each new application of system potentially requires an upgrade.
–Features, Fixes, Bit-rot.
–Secure update mechanism
–Must know/track what upgrades have been made
–Prevent back-leveling.
�Handling changing users, roles, lost passwords, lost keys, etc.
�All these operational issues must be designed in from the
beginning.
IBM Research
25
©2007 IBM Corporation
Planning for Unexpected Upgrades
IBM Research
26
©2007 IBM Corporation
Unplanned software upgrades
�Hardware/Firmware can offer best security but applications/system-
code bugs can effectively neutralize security features.
–XBOX: hardware easily hacked, mod-chips possible [CHES
2002 paper]
–Xbox 360: all external memory seems to be encrypted/mac’ed,
signed system code and games.
•Core hardware still not hacked (no mod-chips) for > 1 year
–BUT: Xbox 360 hypervisorbug (builds 4532-4548 around Oct 2006) allowed
unsigned code to execute with privilege.
–IBM 4758
•Core hardware and secure bootstrap still not broken
•BUT: CCA (Application) API bug can reveal CCA keys [Bond, Anderson,
2001]
�Secure recovery should be built in and back-leveling prevented
–Xbox 360: kernel patched Feb 2007.
–IBM 4758: patched with new version of CCA.
IBM Research
27
©2007 IBM Corporation
Need for upgrading Hardware !
�Most modern CPU’s have significant “errata” that
needs microcode patches.
–Patch is volatile and needs to be re-loaded at every boot.
–Done by BIOS or OS.
–Trend is worsening !
�Hardware bugs can create vulnerabilities
–Multics on several Honeywell machines was subverted by
a hardware bug [early ’70s]
�Secure Hardware patching must be supported and
be designed for
–Certain versions of x86 processors accept unauthenticated
patches !
IBM Research
28
©2007 IBM Corporation
Deploy
�Identification: Is it a device and the right device ?
�Personalization and Privacy
IBM Research
29
©2007 IBM Corporation
The device identification problem (build, deploy, maintain,
decommission)
�How do you know (either locally or remotely) that you
are interacting with a genuine real device and not a
fake or a software emulation ?
–The IBM 4758 solution: Certified root secret key in
hardware protected by tamper-detection and response.
•This is too costly !
•Tamper responsive packaging creates many problems !
–The TCG/TPM solution: Certified EK root key in
hardware, protected against software attacks but not
necessarily against hardware attacks.
•Cheaper, but software-attack only protection too weak for some
applications.
IBM Research
30
©2007 IBM Corporation
Device Identification and the 4758
IBM Research
31
©2007 IBM Corporation
HOW THE IDENTIFICATION PROBLEM BECAME THE SHIPPING PROBLEM
IBM Research
32
©2007 IBM Corporation
Desperate Engineers, Desperate Solutions
IBM Research
33
©2007 IBM Corporation
Device identification problem (continued)
�Silicon Physically UncloneableFunctions (PUFs)
[GCDD 02], [LLGSDD 02] have the potential to offer a
good compromise for Device Identification
–Very clever and evolving idea with potentially multiple
applications ---watch this space.
•Example of converting a “nuisance” into an asset.
IBM Research
34
©2007 IBM Corporation
Physically UncloneableFunctions (PUFs)
�Responses to different challenges, a random function of manufacturing
process variation, is unique to device and not duplicatable.
–Propagation has non-linear effects, feedback can make modeling attacks
harder.
–Circuit could be embedded such that active probing alters function
�Over time, the basic technique has been improved and evolved to create
unique cryptographic keys for each device [G. Edward Suh, SriniDevadas,
DAC 2007].
�Further reading: Using the PUF concept for Intellectual propertyprotection
–Prevent manufacturer from making extra hardware for black market[Alkabani,
Kousahanfar, USENIX Security 2007]
–Paper on PUFsand IP protection from Philips in CHES this year.
�A concern: impact of side-channels on PUFsnot studied
BASIC IDEA
arbiter
Challenge
vector
Pulse
1 if top
path is
faster,
else 0
bit
bit
bit
bit
switch
IBM Research
35
©2007 IBM Corporation
Design/Build/Test
�Large number of unsolved problems in this space
�Some long-standing problems
–Formal verification of designs, as designs get larger.
–Secure composition of H/W and software components.
–Automated testing for security and high assurance.
–Tamper Resistance, side-channel resistance.
–Intellectual property protection, Anti-piracy
�Relatively new problem
–Loss of trustworthiness of the entire design/build/test process for
Hardware and Software
•Significant immediate impact for defense applications.
IBM Research
36
©2007 IBM Corporation
Composition Problem (Design/Test)
�Rare to have software/hardware designed simultaneously by same team.
–Software and Hardware usually built using pre-existing components from
different teams and/or vendors!
�Lack of complete information about components makes it impossible to
make a security assertion about composed system
–Infeasible to re-evaluate every component for each new application.
�Problem has a very long history
–Purple book (Trusted Database Interpretation for TCSEC) tried to formalize
this problem when arguing when a high assurance OS and a high assurance
DBMS that runs on a high assurance OS could be evaluated separately.
•Defined the notion of TCB subsets which rarely occurs in practice
–4758 hardware ratchet mechanism is one example !
–Chicken and egg problem: Don’t know what information about each
component will be needed until the vulnerabilities of the entiresystem are
being analyzed.
•The fact that individual components are “secure” in some contextis meaningless,
Security does not compose !
IBM Research
37
©2007 IBM Corporation
Composition Problem: An example from Caernarvon
�Many hardware RNGshave been evaluated and certified with the
following guidance about use
–The RNG should be tested before use for sensitive operations.
�Wanted to use a certified hardware RNG from a partner for seeding a
pseudorandom number.
–BUT, extensive randomness tests in software on a smart-card
could reveal the random numbers.
•Template Attacks !
–So, tested random numbers must be different from the random
numbers used for seed.
•e.g., Test a first set of random numbers, use a second set as seed
•OR: create three sets, test first and third and use second etc.
–BUT that requires a very specific analysis of the RNG failure mode that
was not part of the evaluation !
IBM Research
38
©2007 IBM Corporation
Other examples of composition problems
�Can a particular secure operating system be implemented on a
processor where certain illegal instructions result in
unspecified state left in some machine registers ?
�Can a secure virtual monitor be built without detailed
knowledge of a platform’s micro-architectural attack
vulnerabilities ?
–These could change at each stepping.
�Can a security protocolusing crypto algorithm A be
implemented on a platform which has side-channel leakage, but
a side-channel resistant implementation of A ?
IBM Research
39
©2007 IBM Corporation
Trustworthy design and manufacturing
IBM Research
40
©2007 IBM Corporation
The Problem: Trustworthiness of current IC supply
Old IC Supply Process
Old IC Supply Process
Current IC Supply Process
Current IC Supply Process
From: DARPA BAA 06-040, Trust for Integrated Circuits
IMPACT: ICs FOR SENSITIVE COMMERCIAL/DEFENCE APPLICATIONS
Trojan inserted by tools
during design
Reverse Engineering
Intellectual Property Theft
Trojan insertion during manufacturing
•Substitution of ICs during
transport
•Modifications to fabrication
process
IBM Research
41
©2007 IBM Corporation
How to detect Trojan insertion [ABKRS 2007]
IBM Research
42
©2007 IBM Corporation
Trojan Detection using IC Fingerprinting
A technique useful for detecting
Trojan Insertion during manufacturing
IBM Research
43
©2007 IBM Corporation
Existing Techniques usable for Trojan Detection
�Detecting IC substitution during transport
–Identification problem.
•Anti-Tamper Techniques and PUFs
�Mitigating problem of Trojan insertion during
manufacturing ?
–What will not to work
•Functional testing of ICs before deployment.
•Destructive validation of a sample of ICs
IBM Research
44
©2007 IBM Corporation
Original Design
Compute F(X)
Output F(X)
Actual Implementation:
Compute F (X)
State Tstate;// Trojan state
Tstate= G(X, Tstate)
If (rare_condition(X, Tstate))
{ Output L ( TState)
} else
{
Output F(X)
}
INPUT
OUTPUT
XF(X)
The Problem: Why functional tests don’t work
Functional Tests
can’t detect
extra computation
Trigger condition
unlikely to
hold during
functional test
NO VISIBILITY INTO INTERNAL
NO VISIBILITY INTO INTERNAL
OPERATION OF IC !
OPERATION OF IC !
IBM Research
45
©2007 IBM Corporation
Idea: Use Side-channels
�Side channels (power, EM) have been used to glean
information about inner workingsof hardware
devices and extract secret keys
�Can side-channels be used to detect Trojan activity
within an IC ?
–Convert a highly successful attack technique into a
defensive technique ?
IBM Research
46
©2007 IBM Corporation
Functional Test + Side Channel Information
Original Design:
Compute F(X)
Output F(X)
Actual Implementation:
Compute F (X)
state Tstate;// Trojan state
Tstate= G(X, Tstate)
If (rare_condition(X, Tstate))
{ Output L ( TState)
} else
{
Output F(X)
}
INPUT
OUTPUT
XF(X)
05
00
10
00
15
00
20
00
25
00
30
00
0246x 1
0−
3
05
00
10
00
15
00
20
00
25
00
30
00
0246x 1
0−
3
05
00
10
00
15
00
20
00
25
00
30
00
0246x 1
0−
3
++ ++0
500
1000
1500
2000
2500
3000
−20246
x 1
0−
3
IBM Research
47
©2007 IBM Corporation
Trojan Detection using Side Channels
�Collect side channel signals during exhaustive
functional testingof genuine ICs and create a side
channel “fingerprint”
–ICs can be later destructively validated.
•Companies like TaeusInternational, Semiconductor Insights,
Portelligentdo such IC “teardowns”.
�Large Trojan activity can be easily detected.
–Large signal differences.
IBM Research
48
©2007 IBM Corporation
Challenge: Small, minimally active Trojans
�E.g.: Trojan tests a trigger condition to activate.
�Trojan signal much smaller than the normal side-
channel signal variations between good ICs.
–variations in manufacturing process !
�We developed an approach that works at least in
simulations.
IBM Research
49
©2007 IBM Corporation
Small, Minimally Active Trojan
50
01
00
01
50
02
00
02
50
0
0
0.0
05
0.0
1
0.0
15
0.0
2
0.0
25
0.0
3
0.0
35
RS
A S
ign
al, P
roce
ss N
ois
e(o
ffse
t),
Tro
jan
Sig
na
l (o
ffse
t)
Tim
e
Power (W)
50
01
00
01
50
02
00
02
50
0
−2
−1
.5−1
−0
.50
0.51
1.52
2.53
x 1
0−
3
R
SA
Sig
na
l, P
roce
ss N
ois
e(o
ffse
t),
Tro
jan
Sig
na
l (o
ffse
t)
Tim
e
Power (W)
Main Signal
Trojan Signal
(checking trigger)
Variation due to
Process Noise
IBM Research
50
©2007 IBM Corporation
600
605
610
615
620
625
630
0
0.0
05
0.0
1
0.0
15
0.0
2
0.0
25
0.0
3
0.0
35
Signal, Noise, Trojan: A closer look in a time-window
signal
process
noise
Trojan Signal
600
605
610
615
620
625
630
−12
−11
−10
−9
−8
−7
−6
x 1
0−
4
Trojan Signal (Trigger Check)
Process Noise Samples
•Process noise highly correlated over time window, limited
degrees of freedom (much less than 30)
•Trojan contribution unlikely to correlate the same way
over time window.
IBM Research
51
©2007 IBM Corporation
Distinguishing Trojan signal from process noise: a technique
�Principal Component
Analysis or Karhunen
Loeve(K-L) analysisof
process noise samples
identifies main orthogonal
dimensions (eigenvectors)
where process noise lies.
�Noise samples then
projected on eigenvectors
ordered by eigenvalues.
�Variation due to process
noise concentrated along
first few eigenvectors.
�Trojan Signal unlikely to lie
solely in those dimensions
�Trojan signal likely to show
up in dimensions where
there is little process noise.
510
15
20
25
30
−8
−6
−4
−202468
10
x 1
0−
4
Projection on Noise Eigenvectors
Process Noise Eigenvectors ordered by decreasing Eigenvalue
Process Noise
from Genuine ICs
Process Noise
+
Trojan Signal
from Trojan IC
IBM Research
52
©2007 IBM Corporation
Experimental Results (via Power Simulations)
IBM Research
53
©2007 IBM Corporation
Simulation: RSA circuit
The Circuit:
RSA encryption macro
�512-bit: equivalent area of 27914 gates, average power consumption: 3.001 mW, Maximum
clock frequency of 617MHz, 5-15% process variation (delays, capacitances etc).
�Multiple Trojans
1.Counter based Trojan:16-bit counter, Area: 406 gates and approx 1.43%of the total circuit
ares, Causes error upon reaching particular counter size
2.A small but “real” 8-bit comparator based Trojan,that creates error upon successful
comparison. (NEVER ACTUALLY TRIGGERED)
•33 gates (0.1% size)
3.A somewhat unrealistic 3 bit comparator Trojan sufficient to test the technique
•Unclocked, 3 gates (0.01% size),(NEVER ACTUALLY TRIGGERED)
IBM Research
54
©2007 IBM Corporation
Results for different Trojans
IBM Research
55
©2007 IBM Corporation
Larger Trojans easily separate from process noise
46
810
12
Eig
envecto
rsTro
jans
Genuin
e
14
16
18
−4
−20Projections 246
x 1
0−
5
IBM Research
56
©2007 IBM Corporation
Even the tiny trojan3 (0.01%) can be detected using statistics
32
34
36
38
40
Eig
en
va
lue
s
+4
sig
ma
42
44
46
48
−2
−1
.5−1
−0
.50
0.51
1.52
x 1
0−
7
36
38
40
42F
als
e P
ositiv
e
− 4
sig
ma
44
46
48
−1
.5−1
−0
.50
0.51
1.5
x 1
0−
7
•Trojan Signals
•Non-Trojan Signals
•� +/-i*� plots
IBM Research
57
©2007 IBM Corporation
Trust Issues with FPGA Design Flows
IBM Research
58
©2007 IBM Corporation
Trust issues in FPGA Design Flow
�Many commercial and defense
applications use FPGA’s
–Need to combine many “cores” from
multiple vendors/pedigrees into a single
FPGA
–Cores usually obfuscated to protect IP.
–Major trust issues
•One core may be designed to
snoop/interfere with others !
•Design tool may be untrustworthy
A
B
CLogical Design
Design
and layout
tools
Physical Layout
Is C snooping on A or B ?
Is A respecting the interface to B?
IBM Research
59
©2007 IBM Corporation
How to ensure a trustworthy FPGA design ?
�Recent research at UC
Santa Barbara & Naval
Postgraduate School: Paper
at IEEE S&P this year
[HBWSKLNI ‘07]
–Title: Moats and Drawbridges:
An Isolation Primitive for
Reconfigurable Hardware
–Moats: Basic Isolation of
cores
–Drawbridges: Interfaces
between components
A
B
CLogical Design
Design
and layout
tools
Physical Layout
Verify the moats and drawbridges
Add moats
and drawbridges
IBM Research
60
©2007 IBM Corporation
Epilogue
IBM Research
61
©2007 IBM Corporation
Success can bring its own problems
�A successful product/device always gets used in
ways that were unanticipated by designers and
creates unanticipated problems
–Technical and Non-technical !
IBM Research
62
©2007 IBM Corporation
Questions