An analysis of the vulnerabilities introduced with
Java Card 3 Connected Edition
Author:
Andrew Calafato
andrew.calafato@ace-tech.eu
Supervisor:
Dr. Kostantinos Markantonakis
2012
Royal Holloway, University of London
Contents
1. Smart cards & their usages
2. Smart Card Operating Systems/Platforms
(Java Card)
3. Attacks on Smart Cards
4. Java Card 3 Connected Edition – new
features, new threats
Smart cards
• Pocket-sized devices with an embedded integrated circuit chip (ICC) and
secure storage
• Microcontroller: offers a secure processing environment (encryption,
integrity, authentication and other security services)
• Memory: to store information in a tamper-resistant security system,
(protecting confidentiality and integrity of data)
– RAM – volatile (non-persistent) - computation working space
– EEPROM/Flash - non-volatile - data storage, applications loaded after
issuance
– ROM – non-volatile read-only memory programmed during manufacture –
OS & permanent data
• Form factors:
–
–
–
–
plastic cards
subscriber identity modules (SIMs) - like ones in mobile phones
USB-based tokens
Fobs
• Contact smart cards - contact pads in direct contact with the reader for
power and data communication
• Contactless smart cards – power and communication through antennae
using radio frequencies (RF)
Smart card Usages
•
•
•
•
•
•
Mobile phone SIM card (Subscriber Identity Module)
Credit/Debit Cards with a chip (chip-and-pin)
Health cards
Pay-TV cards
Contactless travel cards
Access/identity cards
• Eurosmart Smart cards market figures forecast for 2012 (in Millions of Units):
Telecom
Financial Services
Government - Healthcare
Pay TV
Transport
Others
5200
1260
300
120
135
90
Contact
Financial Services
Government - Healthcare
Transport
Others
290
160
95
35
Contactless
Contents
1. Smart cards & their usages
2. Smart Card Operating Systems/Platforms
(Java Card)
3. Attacks on Smart Cards
4. Java Card 3 Connected Edition – new
features, new threats
Operating Systems & Platforms
monolithic
embedded in chip by manufacturers
Rigid architecture
modular architecture
• hardware management
• application level modules
• target application
Shorter time to market
Software reuse
Standard platforms adaptable using
filters (e.g. SIM cards)
Some flexibility
Open Platforms:
• Embedded h/w management layer
• VM for platform independence
• Multiple apps installed after issue
Multi-application execution platforms
Java Card, MULTOS, SmartCard.NET
Java Card
Applets
Extended Applets
Servlets
• Multiple Java Card applications
• Applet container manages classic & extended ISO7816 APDU applets
• Servlet container manages servlet-based web apps
Java Card Runtime Environment (JCRE)
Industry Add on Classes • Libraries providing services / refinements to security & system models
• API classes for
• developing Java Card apps
• providing system services to apps
• application management
Java Card Framework
• transaction management
• I/O communication
• cryptographic functionality
• Executes byte code
• Provides the functions accessible from outside, such as signature,
authentication and applications.
Java Card Virtual
• Controls access to smart card resources (memory, I/O, etc)
Machine (JCVM)
• Secure loading of apps on card post-issuance
• Hides manufacturer's proprietary technology with a common language
and system interface
O.S. & Native Functions
Specific IC and native operating system implementation
Contents
1. Smart cards & their usages
2. Smart Card Operating Systems/Platforms
(Java Card)
3. Attacks on Smart Cards
4. Java Card 3 Connected Edition – new
features, new threats
Smart card Physical Attacks (Hardware)
• Probing bus with microprobes
• Focused Ion Beams & laser cutters to cut/short circuit
• Extreme environment - temperature, light, ionized radiation, high
frequency rays, etc. (semi-invasive)
– E.g. Clock signal / power supply / external electrical field transients to create
glitch attacks to deliberately alter memory locations.
• Combined with mathematical and statistical analysis to compromise
integrity and confidentiality of data
- e.g. a number of papers on applying Differential Fault Analysis (DFA) for
key retrieval
• Countermeasures
–
–
–
–
–
–
programmable active shielding covering the whole chip
sensors, such as infra-red, ultra-violet or visible light sensors, filters
internal voltage, glitch and temperature sensors
proprietary timing and chip layout
scrambled memories and busses (also dynamic per session using scramblers)
software-based countermeasures against fault induction – e.g. integrity checks
Smart card Physical Attacks (Side-channel)
•
Non-intrusive attacks based on the analysis of information achieved through
covert channels to gain information on algorithms/keys
– timing information
– electromagnetic radiation
– power consumption
• Simple Power Analysis (SPA) - power consumption analysis during program execution
• Differential Power Analysis (DPA) - power consumption analysis over known sets of
data vs. some unknown input & statistical extrapolation (algorithm can be unknown)
• High-Order Differential Power Analysis (HO-DPA) - signal readings from multiple data
sources, using different measuring techniques and different time offsets
•
Countermeasures
–
–
–
–
–
–
–
frequency monitoring sensors to avoid clock speed reduction
fast voltage regulators to de-correlate power consumption from instruction execution
introduction of random noise and random wait states
current scrambling/stabilizing techniques
design cryptographic algorithms susceptible to Timing Analysis Attacks
random delays / random ordering of code execution
exclusive use of instructions with similar power consumption
Smart card Logical Attacks
• Can be targeted at the system / infrastructure that the smart card in part of
• Can be launched throughout the whole life cycle of the smart card
–
–
–
–
–
–
–
accidental/deliberate tampering or disclosure of card design, architecture and layout
load Trojan horse & malicious applets
software vulnerabilities such as buffer overflows in all software layers
design and choice of cryptographic algorithms, protocols and key sizes (COMP128 & A5)
man-in-the-middle attack between card and card-reader (EMV protocol)
replay attacks against Static Data Authentication mechanisms
tearing attacks - card is powered off during processing leaving card in an inconsistent or
invalid state, or omitting part of the operation such as incrementing the retry counter
• Countermeasures
–
–
–
–
–
distribution of knowledge to protect from insider threat
physical security to protect from outsider threat
security-relating training and awareness programs for social engineering attacks
software development based on software engineering principles including testing
OS, virtual machines and applications susceptible to timing analysis
Smart card Combined S/w & H/w Attacks
• A number of papers on combining fault injection with logical attacks
• Example 1
–
–
–
–
Power analysis to locate VM type-checking moment in time (class cast exception)
Laser beam to ignore the exception thrown
=> bypass runtime verification
=> reference forgery
=> access memory locations inside application firewall boundary
=> code injection and alteration
• Example 2
– Fault injection to alter Java Card operand stack value
– => corrupt conditional branching
• Example 3
– Alter return address of current function on stack to execute malicious bytecode
• Example 4
– Replacing Java Card opcode with a NOP opcode (represented as 00) to skip instructions
• Countermeasures
– Same as ones discussed in fault attacks
Contents
1. Smart cards & their usages
2. Smart Card Operating Systems/Platforms
(Java Card)
3. Attacks on Smart Cards
4. Java Card 3 Connected Edition – new
features, new threats
1. Complexity
Virtual Machine
Runtime Environment
Applets & Web Applications
Security systems card is part of
all more complex
harder to manage/model security
2. Multithreading
• Parallel execution of processes in web application and extended applet
environments
• A multithreaded runtime environment – can service multiple incoming
requests concurrently & perform multiple executions in parallel
 Inherent complexity of concurrency
– threads interact & intervene with each other (e.g. shared data)
– nondeterministic executions
– logging and debug information lead to different execution order
 More difficult to test and model security (ensure correctness)
 Denial of Service
– deadlock – treads waiting while attempting to acquire each other's locks
– high priority threads cause other threads to starve
 Race conditions
– Explained in next slide
– Need to access shared data atomically – use locks
 Time-of-check to time-of-use (TOCTTOU)
– Example in next slide
– Need to check as close as possible to use
– Preferably make check immutable (check and use in an atomic operation)
Race condition
Thread 1 – add 5 to shared balance
Thread 2 – add 10 to shared balance
Read shared value (100)
Context Switch
Read shared value (100)
Add 10 to it (110)
Store value (110)
Context Switch
Add 5 to it (105)
Store value (105)
The +10 here has been overridden!
Time-of-check to time-of-use (TOCTTOU)
public void setBalance(final BalanceRef balanceParam) {
//check phase
if (balanceParam.getBalance() < 0) {
throw new IllegalArgumentException("Balance cannot be -ve");
}
//reference parameter value can change during this time
//use phase
this.balance = balanceParam.getBalance();
}
3. Web Applications
• A subset of Java Servlet Specification v2.4 is supported => smart cards can
host web applications
 Expanded attack surface
–
–
–
–
HTTP & HTTPS connections (together with APDU)
ports outward facing the network / WWW
More URIs & application services available
All network layer attacks
 Injection Attacks
– Attacker injects untrusted data which ends up being executed unintentionally
by an interpreter (HTML, Xpath, etc) – e.g. comment injection
 Path manipulation / traversal
– Crafting of URL/input to access files & additional capabilities
– use ‛dot-dot-slash (../)’ sequences to move up to parent directories
 Cross-Site Scripting
– Injection of active content - client-side script (e.g. JavaScript, ActiveX,
VBScript, Flash, etc)
• Reflected – e.g. trick user to follow a link injecting script
• Stored/Persistent – e.g. forum / social media
• DOM Based – script act on DOM objects - does not involve server at all
... 3. Web Applications
• Cross Site Request Forgery (CSRF)
– Try to force an authenticated victim to send a forged HTTP request to a
vulnerable application
– Step 1. Attacker forges a request in a way that is acceptable by the target
server
– Step 2. Trick victim to submit the information through a forged request while
authenticated
– Prevention: Synchronizer Token – nonce set to rendered page to be submitted
back with request
• Insecure Direct Object Reference
– Request parameters altered ‘manually’ to reference protected resources
– Prevention: authorization
• Failure to Restrict URL Access
– Whole URL is manually crafted to access protected resources
• Other attacks/vulnerabilities
–
–
–
–
–
DoS (card has restricted environment)
HTTP Response Splitting
Man-in-the-Browser
Session Management vulnerabilities
…
Prevention:
Input validation of any untrusted data
Escape/sanitize before parsing
Authentication & Authorization
Etc.
Other Features
4. Dynamic class loading
– Application can load a class dynamically at runtime as opposed to
explicitly imported
 complicates the type safety enforcement process significantly
 can load class with malicious code
 attacks by Barbu et al. exploited dynamic class loading to create
• ill-formed code injection attacks
• illegitimate modification of applications
• circumvent application firewall
5. Inter-application communications
– Interactions between applications through the application firewall
– Object can offer services to other applications
– notification mechanism using events
 Larger attack surface
 Features can be use in more sophisticated attacks (e.g. Barbu et al.)
Other Features
4. Network Communications (Generic Connection
Framework) through high speed interfaces (e.g. USB)
– TCP/IP, HTTP, SSL/TLS , File Connections, etc
 exposed to attacks targeted at all lower Network Layers
 connected for prolonged period of times
5. Garbage collector
– Process reclaiming unreferenced data
 Another process which can be exploited by attackers (e.g.
Barbu et al.)
Questions?