Secure HardwareSecure Hardware
PA018PA018
Jan Krhovják
Vašek Matyáš
2
Roadmap
Introduction
The need of secure HW
Basic terminology
Architecture
Cryptographic coprocessors/accelerators
Cryptographic chip cards/smart cards
Security categories and common attacks
Physical security
Logical security
Environmental security
Operational security
Security requirements
Standards FIPS 140-1/2/3
Secure HW and famous attacks
3
Why secure hardware
Ensure (fast) secure communication and secure
storage (of extremely critical data)
Sensitive data (e.g., financial data, cryptographic keys)
stored on hard disk or in memory are vulnerable
Adversary (with sufficient rights) can access them
Data in memory can be paged out to disk
Data in a hard disk can be backed up in
unprotected storage device
Problems with secure deletion/destruction
of insecurely stored sensitive data
4
Where secure hardware
Critical applications have always been
banking transactions
Primarily due to need for secure storage
In 70's VISA formed worldwide banking ATM
network
Banks can't trust themselves, their employers or
customers
This led to evolution of so-called Hardware Security
Modules and financial data networks (banking
machines, sales terminals, etc.)
Certification authorities
Primarily due to need for accelerating crypto operations
Increase in the last decade for public-key cryptography
support
5
Basic terminology
Hardware security modules (HSM)
Coprocessors
Accelerators
Cryptographic smartcards
Host devices, API
Attacks on HSMs
Physical attacks
Side channel attacks
Attacks on and with API
We are not interested in any form of DoS attacks!
Top-level crypto keys ­ always stored inside HSM
Other keys can be stored outside HSM encrypted by these
6
Examples of Secure HW
Multi-chip dev.
IBM 4758
IBM PCI-X
SafeNet PSO
SafeNet PSG
Single-chip devices
Gemalto SmartCards
SafeNet iKey
Dallas iButton
Infineon TPM chip
VeriChip RFID TAGs
NXP/Phillips MIFARE
Czech applications
7
Architecture of cryptographic
coprocessors/accelerators
Come out from classical von Neumann architecture
+ Mechanisms of physical protection
Steel shielding, epoxy resin, various sensors
+ Generators of true random numbers
Generating cryptographic material (e.g. keys, padding values)
Algorithmic counter-measurements against side channel attacks
+ Special coprocessors
Accelerating both symmetric and asymmetric crypto
+ Non-Volatile RAM (NVRAM) => retains its content
Connected to a constant power source or battery
Storing sensitive data (e.g. master key)
- I/O circuits
Easier verification
8
Architecture of cryptographic
smartcards
Similar building blocks as coprocessors/accelerators
Everything is inside a single integrated chip
Limited silicon area => small size of RAM
There is only limited power supply in mobile devices
New (U)SIM cards supports DES, RSA and EC cryptography
Their power consumption must be very small
Operating system is stored in ROM, applications in EEPROM
Division according to the communication interface
Contact ­ contain contact pads
Contactless ­ contain an embedded antenna
Combined ­ single chip with both previous interfaces
Hybrid ­ more chips (and interfaces) on single card
Super smartcard =>
9
Security categories
Physical security
Technologies used to safeguard information against physical attack
Barrier placed around a computing system to deter unauthorized
physical access to the computing system itself
Tamper: evidence, resistance, detection, response (more on the next slide)
Logical security
The mechanisms by which operating systems and other software
prevent unauthorized access to data
Access control, algorithms, protocols
Environmental security
The protection the system itself
Access policies ­ guards, cameras ...
Operational security
Cryptographic
coprocessors
Communication
interface
Operational
security
Environmental securityBorder of logical
security
CPU
Memory
Non-volatile
memory
Random number
generator
Border of physical security
Tamper detection sensors
10
Physical security
Tampering ­ the unauthorized modification of device
Tamper evidence
The evidence is left when tampering occurs
Chemical or mechanical mechanisms
Tamper resistance
Only to certain level!
Chemically resistant material, shielding
Tamper detection
Special electronics circuits (i.e. sensors)
Tamper response
Consequence of detection => destroying all sensitive information
Erasing/rewriting/memory destruction
11
Physical invasive attacks
They require a lot of time, knowledge and
specialized equipment ­ probing station =>
Invasive attacks (passive or active)
Direct access to embedded components (ALU, bus, memory ...)
Depacking the device/chip ­ removing the cover (and passivation) layer
Micro probing ­ observing, manipulating or interfering the device/chip
Reverse engineering ­ the process of analyzing an existing
system to identify its components and their interrelationships
Memory readout techniques (e.g. freezing and probing)
Freezing by liquid nitrogen increase data retention time in RAM to hours
12
Physical semi-invasive attacks
They require only low-cost equipment
Easy reproduction of prepared attack
particular device configuration
Depackaging the chip ­ passivation layer remains
Utilizing electromagnetic field, UV light, X-rays,
laser, (local) heating or freezing, irradiation
Optical fault induction
Illumination of SRAM can change its content
SRAM memory with 80x magnification =>
13
Cold boot attacks on
encryption keys
DRAMs memory retention after power is lost
Retain their contents for seconds to minutes
5s 30s 60s 300s
Horizontal bars ­ due design of the memory chip
Sucessful attacks on popular disk encryption systems
BitLocker, FileVault, dm-crypt, and TrueCrypt
For details see: http://citp.princeton.edu/memory/
14
Logical security
Access control
The assumption is existence of trusted environment
Cryptographic algorithm
Mathematical functions ­ only keys should be secret
Ensuring confidentiality, integrity, authentication ...
Cryptographic protocols
Distributed algorithms ­ sets of three to ten messages
Their single steps are created by calling of API functions
API is the only one (exactly defined) communication interface
between HSM and the host application
Economy prevails security ­ too many supported standards in APIs
API of HSM thus contains hundreds functions with many parameters
=> very big space for errors and formation of new attacks
15
Logical (non-invasive) attacks
No physical damaging of device
Monitoring/eavesdropping
TEMPEST attacks (e.g., TEMPEST for Eliza =>)
Electronic devices emits electromagnetic radiation
Reconstructing data from electromagnetic radiation
For more see: http://www.eskimo.com/~joelm/tempest.html
Side channel attacks
Timing analysis ­ measuring the time of cryptographic operations
with respect to input data and algorithm implementation
Power analysis ­ measuring the fluctuations in the consumed
current when the device is performing specific operations
Fault analysis ­ generating of glitches (in voltage, clock signal ...)
Software attacks on and with API
No specialized equipment needed, can be perf. remotely
Very fast and dangerous ­ taking only a couple of seconds!
16
Attacks on and with API
Examples of commonly used API
Public Key Cryptographic Standard (PKCS) #11
Common Cryptographic Architecture (CCA)
Three major problems of cryptographic API
Insufficient ensuring integrity of keys
Problems with backward compatibility (e.g. support of DES or RC2)
Meet in the Middle Attack, 3DES Key Binding Attack, Conjuring Keys ...
Insufficient checking of function parameters
Banking API and working with PINs => PIN recovery attacks
Decimalisation Table Attacks, ANSI X9.8 Attacks ...
Insufficient enforcing of security policy
PKCS #11 ­ only set of functions, designed for one-user tokens
17
Environmental security
The asset is the device itself (not the stored information)
At least interesting aspect of security from analysis perspective
The goal is to limit attacker's opportunity to initiate an attack
Creating layers of hindrance (e.g. access control&policies)
Monitoring ­ using (infra/thermal) cameras
Not necessarily applicable to HSMs operating in hostile
environments (typically highly physically secured)
Administrators of HSMs (i.e. security officers) have a certain amount
of power over a HSMs that can be misused
To prevent single security officer from compromising the system, the
principle of dual control policy is enforced
At least two security officers (e.g. from different banks) must agree to change the
device configuration (e.g. installing/changing of keys)
At least two security officers must collude to circumvent the security
Administrative/procedural controls should be the part of security policy
whenever is it possible
18
Operational security
HSM can be operated only trough functions of API
With API functions can programmer interact by keyboard
Some devices allows the user to execute limited number of
exactly defined API commands (e.g. ATMs by PINpad/keypad)
The security risks related to proper manipulation with
cash machines and their interfaces are growing
The user should be able to recognize the fake
Payment terminal, ATM, card reader =>
The user should know what to do with keypad
The user should operate cash machine alone
The user should be aware of latest attacks as
Transparent overlay of keypad, Lebanese loop =>
The user should safeguard his PIN
19
Classes of adversaries I
Class 0 (script kiddies)
No knowledge of the system
Exploit existing tools (trial-and-error method)
Class 1 (clever outsiders)
Often very intelligent
Insufficient knowledge of the system
Access to only moderately sophisticated equipment
Exploit existing weakness in the system
Class 1.5 (well-equipped outsiders)
Very intelligent with basic knowledge of the system
Low-cost equipment to build new attacks
Specialized laboratories in universities, etc.
20
Classes of adversaries II
Class 2 (knowledgeable insiders)
Specialized technical education and experience
They understand the parts of system + typically have
access to most of it
Access to sophisticated tools and instruments for analysis
Class 3 (funded organizations)
Teams of specialists (can be from Class II)
Related and complementary skills
Capable of in-depth analysis of the system
Use of the most sophisticated analysis tools
Design of new sophisticated attacks
21
Security requirements on
HSM: FIPS 140-1/2 (I)
Related to design and implementation of HSM
Some of 11 areas of security requirements:
Cryptographic module specification
Cryptographic module ports and interfaces
Role, services, and authentication
Physical security
Operational environment
Cryptographic key management
Mitigation of other attacks
...
Testing and independent rating in each area
=> 4 overall levels of security (level 4 = best)
22
Security requirements on
HSM: FIPS 140-1/2/ (II)
Standard defines 4 levels of security
Level 1 ­ no physical security required
At least one approved security function
Classical example ­ cryptographic software for normal computers
Level 2 ­ temper evidence required
Role-based authentication
OS must be evaluated
Classical example ­ smart card
Level 3 ­ tamper detection & response required
Authentication based on identities
Example ­ Chrysalis-ITS Luna CA3
Level 4 ­ environmental failure protection/testing
Example ­ IBM 4758 or IBM PCIXCC
23
FIPS 140-2 in detail
24
First draft of FIPS 140-3
Each of 11 security areas redefined + added fifth security level
Strengthening of several requirements
Physical & software security (new area)
Protection against non-invasive attacks
Most important changes
Authentication
Definition of roles and services (1); role-based or identity-based
authentication (2); identity based operator authentication (3);
two-factor authentication (4,5)
Non-invasive attacks
No requirements (1,2), protection against time analysis (3), protection against
simple/differential power analysis (4), protection against electromagnetic
emanation (5)
Self-tests
Continuous RBG testing, RBG entropy source test
25
Famous attacks I
Security of Mifare RFID tags
Reconstruction of integrated circuit
from photos of chip
Chip has several thousand gates,
but only ~70 different types
16-bit RNG based on LSFR
Seed derived from value of read
Time delay between power on and the reception
of message data from the contactless card reader
No non-linear component in feedback
Output derived only from fixed subset of bits
For details see
http://events.ccc.de/congress/2007/Fahrplan/events/2378.en.html
http://www.smartcard.co.uk/mifare.html
26
Famous attacks II
Cipher Instruction Search Attack on the Bus-Encryption
Security Microcontroller DS5002FP
Effective and cheap attack => class of adversary I
Encryption of data bus and external address
Secret key is stored in battery buffered register inside chip
External RAM contains encrypted data on encrypted address
Sending suitable instructions and observing their effects
MOV 90h, #42h (encoded as 75h 90h 42h) outputs byte value 42h on
parallel port P1 (address 90h)
216 combinations for the first two encrypted instruction bytes
Testing 28 values for first byte => decryption for one address
NOP followed by MOV increases the address from which is MOV fetched
For details see
http://csdl.computer.org/dl/trans/tc/1998/10/t1153.pdf
http://www.cl.cam.ac.uk/~mgk25/tamper.pdf
27
Famous attacks III
Reverse engineering of Chrysalis-ITS (Safenet) Luna CA3
Certified at FIPS 140-1 Level 3
Examination of vendor-specific functionality (cloning protocol)
Interesting findings
Disassembling shows no potting material
Only red glue ­ maybe for structural integrity or head dissipation
Proprietary Luna API (translated to PKCS#11 by higher-level lib.)
Found number of undocumented Chrysalis PKCS#11 extensions
Owners of key material stored in device can extract private key
material (to the clear) or migrate them into other LunaCA3 devices
For details see
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-592.pdf
28
Famous attacks IV
IBM 4758 (with CCA API)
HW & FW are certified at FIPS 140-1 Level 4
Layered design
Higher layers confide in lower layers
HW and FW are under control of IBM
SW controls the owner
Surprisingly easy logical attacks on CCA API
For details see
http://www.cl.cam.ac.uk/~mkb23/research/PIN-Cracking.pdf
http://www.cl.cam.ac.uk/~mkb23/research/Thesis.pdf
http://www.cl.cam.ac.uk/~mkb23/research/CCA-EMV.pdf
http://www.cl.cam.ac.uk/~mkb23/research/Clulow-Dissertation.pdf
29
Conclusions
Secure hardware
Limited functionality ­ easier to verify ­ better security (than
multipurpose hardware)
Dedicated circuits ­ faster than software implementation
Secure hardware doesn't guarantee absolute
security
Any secure hardware can be reengineered
Main reason of its usage is increased cost of attack
And also better performance of demanding crypto operations
Bad design and integration imply attacks
The security of current generation banking APIs is really bad
with respect to insider attacks
Number of standards implemented ensures interoperability
but also causes errors
30
Course reading ­ week 3
Cryptographic Processors ­ A Survey
R. Anderson, M. Bond, J. Clulow and S. Skorobogatov
http://www.cl.cam.ac.uk/~mkb23/research/Survey.pdf