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 46 F8


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

http://mesure.gforge.inria.fr/


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

Technology