Java Card Platform Security and Performance

1 Copyright © 2011, Oracle and/or its affiliates. All rights
reserved.
Insert Information Protection Policy Classification from Slide 8
Java Card Platform Security
Eric VETILLARD
Sr. Principal Product Manager, Java Card

reserved.
Program Agenda
• Security? What security?
• Some Threats to Consider
• Protecting your Assets
• Protecting GlobalPlatform
• Protecting the Virtual Machine
• Protecting your Applications

reserved.
Java Card is about Security
• Java Card targets secure microcontrollers
– Typically used as security tokens
– Very often containing sensitive and confidential data
– Very often controlling access to sensitive/valuable assets
• Security depends greatly on the implementation
– The Java Card Specification defines principles
– A robust and bug-free implementation is required
– In addition, security certifications are common requirements

reserved.
Purpose of this Presentation
• Identify some key security requirements for Java Card
– Threats that are likely to be encountered
– Mechanisms that require protection
• Propose a few mechanisms/solutions
– To enhance the security of a platform
– To increase the platform developers’ awareness of security

reserved.
Program Agenda

reserved.
Hardware Attacks
• Power analysis
– Leaking data by analyzing the execution
– Many ways to exploit power analysis today
• Following bytecode execution, attacking comparisons, etc.
• Fault induction
– Modifying the behavior of the platform
– Becoming very accurate, better than hardware countermeasures
• Not considering crypto attacks here

reserved.
Software Attacks
• Typical process
– Loading a malicious application
– Run the malicious application to perform attack
• Systematically used in attack preparation
– Attackers is a developer; possesses card management keys
– Unverified applications can be freely loaded
• Very uncommon in actual attacks
– Attackers don’t have the real card management keys
Attacking the Virtual Machine

reserved.
Quotation of Attacks
• A standard scale is used to quote the attacks
• The scale is a combination of criteria
– Criteria are applied on identification and exploitation
From Common Criteria
Elapsed time Hour, day, week, month, more, too much
Expertise Layman, professional, expert
Knowledge of target Public, restricted, sensitive, critical
Access to target <10, <100, >100, too much
Equipment None, standard, specialized, bespoke

reserved.
Attacks to Consider Possible
• Full flash/EEPROM memory dump
– Very useful to analyze the platform and select attacks
– Should NOT reveal any secret of any kind
• Execution of illegal code in attacker’s context
– A rogue application executing in its own context
– But, it could exploit any default in your firewall
• If that happens, other applications’ assets can be endangered
• Basic SPA/SPA/fault induction attacks
– Include enough redundancy and checks
And to defend against

reserved.
Program Agenda

reserved.
Remember the Objectives of Attacks
• Disclosures are often considered the worst thing
– Disclosure of a secret key
– Disclosure of a PIN
• Unauthorized modification is not good either
– Modification of a PIN
– Modification of a public key
• Some other things may also be problematic
– Accepting a wrong signature
– Disabling a security counter
What vulnerabilities are critical?

reserved.
Protecting Assets is Essential
• Instances of key API classes
– OwnerPIN
– All keys
• Application data
– Security counters
• System data
– Global encryption keys
– Applet table and other meta-data
What assets to protect?

reserved.
Protecting a PIN
Unprotected storage
OwnerPIN 02 03 ref ref
boolean[1] ptr F
byte[4]] 01 02 03 04
PIN Try Counter
PIN Try Limit
Presentation flag (in RAM)
PIN value (cleartext)

reserved.
Protecting a PIN
Protected storage
OwnerPIN FD02 FC03 ref ref
byte[1] ptr A5
byte[4]] 3E 82 47 8B
PIN Try Counter (redundant)
PIN Try Limit (redundant)
Presentation flag (redundant)
PIN value (encrypted)01 76 46F8

reserved.
Protecting a PIN
• Very bad: Obvious comparison
– Compare byte per byte, fail on first difference
– 20 tries on average to get to the correct 4-digit PIN
• Bad: Full comparison
– Compare byte per byte, always do full compare
– Any visible trace of failure brings back to previous case
• Better: Encrypted comparison
– Encrypt proposed value, compare to reference
– Then, any comparison will do: no leak on the value
PIN comparison

reserved.
Protecting a PIN
• Protecting the PIN counter
– Attackers will try to get more tries
– Always decrement the PIN counter first
– Be very careful about fault induction
• Protecting against fault induction
– Always verify the checksum
– Read only once from memory
– Valid for all data (PIN value, counters, flags)
Everything else

reserved.
Protecting your Global Assets
• Some crypto keys are used to encrypt keys and PINs
– These keys are essential for the platform’s security
– Attackers will look for them
• Be very careful with these keys
– Always assume that attackers can get a full memory dump
– Do not store these keys in an obvious way (16-byte chunk)
– Try to diversify whenever possible
Platform encryption keys

reserved.
Program Agenda

reserved.
Why Protect GlobalPlatform?
• GlobalPlatform is used to manage content
• An attacker who breaks GlobalPlatform’s security
– Can load illegal applications
– May be able to modify some application’s data
– May be able to modify some card-level secrets
• The Secure Channel must be well protected
– Especially if the Virtual Machine is not very protected
The Key to your Cards

reserved.
How to Protect GlobalPlatform?
• Content management (in the field) requires integrity
• Make sure that integrity checks can’t be bypassed
• Make sure that CLA tests can’t be bypassed
The Secure Channel is the key
80 E6 04 00 Lc Data 00 … 00
00 E6 04 00 Lc Data

reserved.
Program Agenda

reserved.
Which Protection for the Virtual Machine?
• The Cost vs. Security balance is hard to find
– Any additional check in the interpreter is costly
• Illegal access to local frame is most dangerous
– Especially is system frame data is in the stack
• Alternatives may be possible
– Organize data in alternative ways
– Use the MMU to perform checks

reserved.
Risks in the Local Stack
LV0
LV1
LV2
Return PC
Old TOS
Old LV
Old Context
TOS
TOS
Accessible as LV3
Replaceable after pop
…

reserved.
Program Agenda

reserved.
Enforce the Firewall
• Use the hardware protections when available
– Isolation by MMU
• Very efficient, not always really adapted
• Requires the allocation of memory chunks (quota management)
– Low-level encryption
• With a specific key for each context
• Very good compromise between performance and security
• Make cross-context accesses highly redundant
– Performance impact is minimal, since such accesses are rare
Global system-level protection

reserved.
Clearly Split Responsibilities
• Make sure to follow well-known security guidelines
– For both platforms and applications
– Maintain the guidelines properly
Platform and applications are complementary
Java Card
Application
Developer
Handbook
Test and
Inspection
Process
Interop
and
Security
Guide
Java Card
Platform
Defined by Issuer
Applied by Providers

reserved.
Q&A

reserved.

reserved.
Java Card Platform Performance
Eric VETILLARD
Principal Product Manager, Java Card

reserved.
Program Agenda
• Know your platform(s)
• Optimizing Bytecode Interpretation
• Optimizing Libraries
• Optimizing Application Loading
• Optimizing Your Applications
• Limits of Interoperability
• A Continuous Process

reserved.
Performance is Complicated
• Performs comes from a combination of many factors
– Hardware performance
– System software performance
– Application tuning
• Performance is only one of the parameters
– Also consider security, maintainability, portability, and more
• Learning to identify bottlenecks is a long process
– When performance becomes an issue, it may be too late to start
And often unpredictable

reserved.
Measure Performance
• Performance is an issue or will be someday
– When your platform becomes more complex
– When contactless requirements arrive
• Prepare standard benchmarks
– Using standard use cases
– Using unit benchmarks to measure specific features
• Run benchmarks often
– Compare to competitors or to your older/other platforms
– Monitor the evolution, and compare to your expectations
Benchmarking is part of testing

reserved.
Standard Benchmarks
• Measuring can be challenging on standard machines
– Timing is not precise enough for good measurements
– For proper timing of specific features, use large loops
• Measure the time of the loop minus the time of the empty loop
• Divide by number of loops, and you get micro/millisecond precision
• Check the Mesure Project (http://mesure.gforge.inria.fr/)
– Plenty of tests available, together with a benchmarking platform

reserved.
Differential Benchmarking
• Benchmarks can contain measurement errors
– A bug in the benchmark or in its exploitation
• Comparisons are much safer
– Even with measurement errors, comparisons make more sense
• Comparisons are much more useful
– It is normally possible to know what change is expected
• The clock is going twice faster, so should the code
– Comparing with expectations helps understand the possible issue
Comparing is better than just measuring

reserved.
Where is your Bottleneck?
Bytecode; 20%
Native; 10%
Writing; 25%
Crypto; 20%
I/O; 25%
Bytecode interpretation isn’t everything

reserved.
Program Agenda

reserved.
Optimizing Standard Bytecode
• Be careful with programming style
– Method invocation can be expensive
– Too much modularity can hide bottlenecks
• Help your compiler
– Make sure that optimizations are well performed
– Force the assignment of key variables in registers
• Assembly vs. C
– Impact is limited if C code is designed for performance
Limited Options

reserved.
Focus on the Right Things
• Bytecode interpretation is simple
– A loop (don’t waste cycles at every round)
– Many simple instructions (easy to optimize, assembly possible)
– A few complex instructions (mostly object access)
– Exception management (can be tricky)
• Memory management is complicated
– Object representation (optimizing the checks)
– Memory structure and object allocation (critical in real use)
– Caching, atomicity (reducing the number of write operations)

reserved.
Focus on Mainstream Cases
• Example 1: Firewall checks
– Make the standard case (same context) as fast as possible
– Second, focus on accessing system objects
– For all other cases, performance is not an issue
• Example 2: Exception catching
– Exceptions normally occur in error cases
– If so, no need to optimize this process: Errors will be slow
– Don’t forget to tell application developers
Unfrequent cases don’t affect performance

reserved.
Program Agenda

reserved.
Beware of Java Layers
• Example: The crypto library
– The entire API is made of interface and abstract classes
– Don’t use complex patterns for abstract classes
• Signature.doFinal() should go straight to the computation
• No analysis/switch/decision/abstraction at this stage
– Crypto APIs may be used repeatedly with small operations
– In such cases, the Java part of the invocation can be longer than
the (native) computation itself
– This should be measured during development
Some constructs can be costly

reserved.
Go Native?
• When Java’s safety makes no sense
• Util.arrayCopy() is the best example
• If written in Java, 90% of the time is spent in useless checks
• When a process is computationally intensive
– Cryptography, biometrics, etc.
• For security reasons (PIN checks, for instance)
– To better hide the ongoing processing
– To include specific countermeasures
When to more from Java to C?

reserved.
Going Native Securely
• Perform all required tests
– Example: Before to perform an array copy
• Check both references as being of the right type
• Check the size of both arrays
• Perform the firewall checks
• Then, do the copy (without redoing the checks at every operation)
• There have been many implementation bugs in the past
– Especially with missing/incorrect firewall checks
– Consequences can be really bad
Don’t compromise your platform

reserved.
Program Agenda

reserved.
Is Application Load too Long?
• CAP file linking is not efficient
– The method component is written twice in EEPROM
– The constant pool is written for nothing
• Application loading usually in parallel with GP crypto
– MAC computation is performed during the load operation
The loading process is not optimized

reserved.
Simple Ways to Optimize Linking
• Keep the constant pool in RAM
– If there is enough RAM available
– Saves some useless EEPROM writes
• Optimize processes
– Optimize the number of write operations
• Use the largest write cache page available
– Try to parallelize I/O, memory writes
• Forget interoperability
– It is possble to drastically reduce the number of EEPROM writes
Full interoperability

reserved.
Program Agenda

reserved.
Know your Platform (bis)
• Managing write operations properly
– Persistent write operations are always costly
– With atomicity, things are much worse
– Developers should know what the best option is
• Identifying bottlenecks
– Some performance problems are usually known
– Ensure that application developers are aware of them
• Compare platforms
Teaching developers to be careful

reserved.
Beware of Java constructs
• “Big” Java developers are used to JIT
– Java’s inefficiencies are compiled away
– No such optimization occurs on Java Card
• Method invocations are costly
– Getters and setters may not be such a good idea
– Put some limits on the code’s structure
• Virtual methods and inheritance are costly
– In particular when interfaces are used
– Don’t structure too much the code within an application
Remember, no JIT on Java Card

reserved.
Perform Local Optimizations
• Use return; or break; as soon as possible
– Avoid “goto” strings in the bytecode
• Cache values and references in local variables
– Computing obj[i].scp.key[j] is expensive
• Two field accesses, two array access
• Four null checks and firewall checks, two boundary checks
– If you need it twice, cache the value in a local variable
• Use exceptions for error handling
– No cost on main (successful) case
Local actions, global impact

reserved.
Program Agenda

reserved.
Forget Interoperability?
• The Java Card bytecode is reasonably optimized
– Reduced instruction set
– Combined instructions such as getfield_s_this
• It is possible to go much further
– The resulting code is not interoperable
– Not acceptable for downloadable code
– Not a problem for platform code or preloaded code
In some cases, a very good idea

reserved.
Forget Interoperability?
• What ideas would be worth trying?
– Optimize the instruction set aggressively
– Use a different VM structure
– Compile some code into native code
• Some obstacles stand in the way
– Such optimizations are usually costly in space
– Specific tools need to be developed
• These tools are often complex to write
Some potential, many challenges

reserved.
Closed Platforms
• Some platforms are closed, “Java Card S” platforms
– No post-issuance download (and install) of applications
– Fixed set of applications
• Such platforms can be optimized
– No need for loader/linker or other post-issuance software
– No need for full API support
• The subset required for the fixed set of applications is sufficient
– No need for binary-level interoperability
• JCRE and VM can be optimized as required
Reducing the footprint

reserved.
Closed Platforms
• We have released a Trimming Tool in SDK 3.0.3
– Analyzes a set of applications
– Determines which APIs are required by the applications
• Using the Trimming Tool on a platform
– First develop a modular platform, from which APIs can be removed
– Pass the TCK on the full modular platform
– Then analyze the target applications
– Generate the subset platform required for the target applications
– Use this subset platform with the applications as a closed product
Using the Trimming Tool

reserved.
Program Agenda

reserved.
Performance is One Side of Life
• Footprint
– Size constraints are often quite tight
– Platform code must be at least reasonably optimized
• Security
– Security constraints can be very invasive
– Redundancy is bad for both performance and footprint
• Maintainability and portability
– Dedicated, optimized code is harder to maintain and port
There are many other aspects

reserved.
The Doom Cycle of Optimization
• Step 1: Implement without optimizing
• Step 2: Add performance in the picture
– Some things are too slow
– Update design and go to Step 1
• Step 3: Add footprint in the picture
– Performance optimizations made the platform too big
– Update design to reduce size and go to Step 1
• Step 4: Add security to the picture
– Security countermeasures make the platform too big and slow
– Update design (or redesign completely), and go to Step 1
Failing without grace

reserved.
Consider All Constraints First
• Consider all the constraints at once
– Understand that “just enough” is not enough
• Some time will be wasted by security, require 20% better performance
– Use a secure design rather than a secure implementation
• Example: Increase PIN counter first, compare encrypted values
• This is not easy: Requires architecture skills
– First time will be difficult
– Subsequent times will be easier, as experience grows

reserved.
Q&A

reserved.

Java Card Platform Security and Performance

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (6)

Andere mochten auch

Andere mochten auch (15)

Ähnlich wie Java Card Platform Security and Performance

Ähnlich wie Java Card Platform Security and Performance (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Java Card Platform Security and Performance