Secure Hardware
PV018
Masaryk University
Faculty of Informatics
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 and FIPS 140-2
Programmable cryptographic coprocessor IBM 4758
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
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
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
7
Architecture of cryptographic
smartcards
Similar building blocks as coprocessors/accelerators
Everything is inside a single integrated chip
Problems with limited silicon area => only 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 =>
8
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
9
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
10
Physical attacks
Invasive attacks (passive or active)
Direct access to embedded components (ALU, bus, memory ...)
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 can increase data retention time in RAM to hours
They require a lot of time, knowledge and specialized equipment
Semi-invasive attacks (only on integrated chip cards)
Depackaging the chip, but the passivation layer remains
Utilizing UV light, X-rays, laser, electromagnetic field, local heating
Optical fault induction ­ illumination of SRAM can change its content
They require only low-cost equipment
Easy reproduction of prepared attack for the same HW, FW, SW
11
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 attacks
12
Logical attacks
Non-invasive attacks
No physical damaging of device
Monitoring/eavesdropping
TEMPEST attacks
Electronic devices emits electromagnetic radiation
Reconstructing data from electromagnetic radiation
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
They are very fast ­ taking only a couple of seconds
13
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
14
Example of attack on API:
Conjuring Keys From Nowhere
Unauthorized generating of keys stored outside HSM
Random value of encrypted key is given to HSM
Older HSMs used this technique to legitimate key generation
Today is it considered as attack
After decryption is the value of key also random
In the case of DES has with probability 1/28 good parity
DES key is stored with odd parity ­ LSB in each octet is parity bit
In the case of two-keyed 3DES-2 has a good parity with probability
1/216 (and this is still achievable)
These keys can served to form more complicated attacks
The defense lies in carefully designed key formats
=> e.g. add before encryption checksum + timestamp
15
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 by
creating layers of hindrance (e.g. access policies, controls)
Not necessarily applicable to HSMs operating in hostile
environments (they are typically highly physically secured)
The exception are the administrators of HSMs (i.e. security officers)
They 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
16
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 he 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
17
Classes of adversaries I
Class 0 (scripting 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.
18
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
19
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)
20
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
21
FIPS 140-2 in detail
22
IBM 4758 PCI CC =>
IBM PCI-X CC (new) =>
Programmable cryptographic
coprocessors
HW & FW are certified at Level 4
Layered design
Provided SW is a sample application
(without guarantees)
Many customers use it (to their damage )
Higher layers confide in lower layers
HW and FW are under control of IBM
SW controls the owner
23
Performance of IBM CC
Comparison of IBM
cryptographic
coprocessors =>
IBM PCIXCC encryption
24
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