First Steps with Java Card

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 13 1

First Steps with Java Card

Eric Vétillard

Sr. Principal Product Manager, Java Card


Java Card Main Use Cases


Smart Cards are About Tamper Resistance

Tamper resistance is about resisting to attacks

– Not just against software attacks coming from the Web

– Also from all kinds of physical attacks

Observation attacks, where attackers listen to your device

Fault attacks, where attackers use lasers and more to derail silicon

Using a smart card with a Java Card application gives you

– A physical isolation from the client system and the Web

– A physical protection against most direct attackers

Java Card is Java on a smart card


Java Card can Protect Your Credentials

Your application will most likely manage some credentials

– PIN codes or passwords

– Cryptographic keys

Java Card products will protect these credentials

– With specific countermeasures on all sensitive classes

– With standard management procedures, such as GlobalPlatform

You are only responsible for your application logic

Your design, our protection


How Much Should You Know About Security to Use Java Card?

Java Card doesn’t require any specific security skill

– It is a dialect of Java targeting smart cards

Smart card development requires some security skills

– What if your application returns a password as cleartext?

– Some security experience is required

In particular if you design your own applications


What About Security Certifications?

Some industries require security certifications

– In most cases, Common Criteria or FIPS140

– For instance, payment, identity, government apps, etc.

Security certification requires specialized skills

– Not necessarily yours, many consultants are available

Java Card provides you with significant help

– The most difficult work is done by platform providers

– Application developers only need to “prove” their application secure

While relying on the Java Card security mechanisms


First Steps with Java Card


Protect passwords by storing

them in a smart card, using a

Java Card Classic applet

Make sure to follow best

security practice in this

development

Idea

Example: Password Storage


The Functions

Keep a base of login records

– Identifier, username, passwords

Allow basic operations

– Add a new record

– Lookup a record (by identifier)

– List all identifiers

– Modify a record

– Delete a record

Very basic


Java constructs supported

– Classes, interfaces, …

Limited basic types

– Byte, short, (int)

– No char, no float

Limited libraries

– No Strings, no containers

A Subset of Java

Implementation

class PasswordEntry { private byte[] id; private byte[] userName; private byte[] password; private byte idLength; private byte userNameLength; private byte passwordLength; byte getId(byte[] buf, short ofs) { return Util.arrayCopy(id, (short)0, buf, ofs, idLength); }


Objects are persistent

– Stored in flash memory

No garbage collection

– Too time-consuming

– Objects allocated statically

Back to “classical” algorithms

Specific memory

Implementation

private PasswordEntry next; private static PasswordEntry first; private static PasswordEntry deleted; private PasswordEntry() { id = new byte[SIZE_ID]; userName = new byte[SIZE_USERNAME]; password = new byte[SIZE_PASSWORD]; // Insert elt in front of list next = first; first = this; }


Write operations are dangerous

– Writing is long and error-prone

– Power is external

Atomicity is required

– Transaction mechanism

– Single write atomicity

Atomicity

Implementation

static PasswordEntry getInstance() { { if (deleted == null) { return new PasswordEntry() ; } else { PasswordEntry instance = deleted; JCSystem.beginTransaction(); deleted = instance.next; first = instance; instance.next = first; JCSystem.commitTransaction(); return instance; } }








Atomicity

Implementation

static PasswordEntry getInstance() { { if (deleted == null) { return new PasswordEntry() ; } else { PasswordEntry instance = deleted; JCSystem.beginTransaction(); deleted = instance.next; first = instance; instance.next = first; JCSystem.commitTransaction(); return instance; } }








Atomicity

Implementation

private PasswordEntry next; private static PasswordEntry first; private static PasswordEntry deleted; private PasswordEntry() { id = new byte[SIZE_ID]; userName = new byte[SIZE_USERNAME]; password = new byte[SIZE_PASSWORD]; // Insert elt in front of list next = first; first = this; }


Java Card Programming Style

Need to deal with many constraints

– Very limited memory management

– Limited computing power (except for crypto)

– Limited utility classes

Automation remains limited, developer needs to think

– Static allocation of objects: counting bytes

– Keeping track of atomicity

– …

Java outside, embedded inside


The Security

Access control

– Require a master password before to allow usage of the application

– Valid as long as the application is selected

No secure channel requirement

– A bit optimistic, but assume that there are no hackers on the PC

Analyzing requirements


Applets are the basic class

– Processing APDU commands

– Following ISO7816 standards

Security mechanisms are provided

– For instance, a PIN

– With “secure” implementation

Basic framework

Interface and Security

public class PasswordMgr extends Applet { public final static byte INS_ADD_PASSWORD_ENTRY = (byte)0x30; public final static byte INS_FIND_PASSWORD_ENTRY = (byte)0x32; public final static byte INS_LIST_IDENTIFIERS = (byte)0x34; public final static byte INS_VERIFY_PIN = (byte)0x38;

private OwnerPIN pin ; public PasswordMgr() { pin = new OwnerPIN(3,16); }








Basic framework











Basic framework











Basic framework











Basic framework





Applets need to be installed

– Instantiation and registration

Applets need to be selected

– Session data is initialized

Deselection is also provided

– To clear some things

Lifecycle and sessions


public static void install( byte[] ba, short ofs, byte len) { (new PasswordMgr()).register( ba, (short)(ofs+1), ba[ofs]); } public boolean select() { return true; } public void deselect() { pin.reset(); }










































The JCRE invokes a method

– Passing the command

– Using a dedicated class

The buffer is used in most cases

– Following ISO7816



Processing commands


public void process(APDU apdu) { if (selectingApplet()) return; byte[] buf = apdu.getBuffer(); switch(buf[ISO7816.OFFSET_INS]) { case (byte)INS_ADD_PASSWORD_ENTRY: checkAuthenticated(); processAddPasswordEntry(apdu); break; case (byte)INS_VERIFY_PIN: processVerifyPIN(apdu); break; …









Processing commands











Processing commands











Processing commands









Everything is checked

– To strictly cover the spec

Processing commands


public void checkAuthenticated() { if (pin.isValidated()) return; ISOException.throwIt( ISO7816.SW_CONDITIONS_NOT_SATISFIED); } public void verifyPIN(APDU apdu) { byte[] buf = apdu.getBuffer(); if (Util.getShort(buf, ISO7816.OFFSET_P1)!=0x80) ISOException.throwIt( ISO7816.SW_INCORRECT_P1P2); …









Processing commands











Processing commands











Processing commands


if (pin.getTriesRemaining()==0) ISOException.throwIt( ISO7816.SW_DATA_INVALID); if (buf[ISO7816.OFFSET_LC]==0) { if (pin.isValidated()) return; else ISOException.throwIt( ISO7816.SW_WRONG_PIN + pin.getTriesRemaining()) ; } short len = APDU.setIncomingAndReceive(); verify(buf, ISO7816.OFFSET_CDATA, (byte)len);









Processing commands











Processing commands











Processing commands




First the initial checks

– Here, checking the PIN length

– Always check everything

Then, the comparison

And then the result

– Building the right response

Verifying a PIN


void verify( byte[] buf, short ofs, byte len) { if (len > 16) ISOException.throwIt( ISO7816.SW_WRONG_DATA); if (!pin.check(buffer,ofs, len) { if (pin.getTriesRemaining()==0) ISOException.throwIt( ISO7816.SW_DATA_INVALID); else ISOException.throwIt( ISO7816.SW_WRONG_PIN+ pin.getTriesRemaining()); } }






And then the result


Verifying a PIN








And then the result


Verifying a PIN








And then the result


Verifying a PIN




The Security

What if the user forgets the password or loses the card?

– A backup can be produced, encrypted with a key

How to protect the backup?

– With a secret key, if this is for private use

Then, don’t forget/lose the key

– With a public key, if this is in a commercial offer

Decryption requires fee payment, and offline authentication method

Smart cards don’t solve all the problems …

Tricky stuff


The Security

Remember why you are using a smart card

– Because is it tamper-resistant

– So, what happens when the card is under attack?

Under attack, some countermeasures are activated

– At the hardware level

– At the system software level

– At the application software level

Protecting against attacks


The Security

A typical attack consists in leaking information from the card

– Many different ways of doing it, many countermeasures too

– Typical application-level countermeasure:

Assume that the other countermeasures have failed

Encrypt your data to make it unexploitable

Another attack consists in provoking faults in the execution

– Shorting the silicon, exploiting physics

– In software, redundancy is the only direct countermeasure

What attacks? What countermeasures?


Java is practical here

– Encapsulation works

– Encryption is local to class

Java Card crypto is simple

– Inspired from JCE

– Implementation protects keys

Encrypting objects

Protecting Against Observation Attacks

byte getUserName(byte[] buf, short ofs) { unCipher.init(unKey,Cipher.MODE_DECRYPT); unCipher.doFinal(userName, (short)0, userName.length, buf, ofs); return getUserNameLength(); } byte getPassword(byte[] buf, short ofs) { password.getKey(buf,ofs); return getPasswordLength(); }








Encrypting objects










Encrypting objects




Java is not really practical here

– Encapsulation doesn’t work

– Checks are everywhere

– Code is very hard to read

Requires some specific skills

– Not that hard to acquire

Adding redundancy

Protecting Against Fault Attacks

boolean verify( byte[] buf, short ofs, byte len) { byte tl = triesLeft; if (tl != (short)(~triesLeftBak)) takeCountermeasure(); if (tl<=0) return false; JCSystem.beginTransaction(); triesLeft = --tl; triesLeftBak++; JCSystem.commitTransaction(); if (triesLeft != (short)(~triesLeftBak)) takeCountermeasure();








Adding redundancy










Adding redundancy










Adding redundancy










Adding redundancy










Adding redundancy




Java Card is Simple

Using Java Card is rather simple

– Allows you to program card applications

– Provides access to required functions such as PIN and cryptography

Your applications are not simple

– They are part of a larger, more complex system

– If they need to be on a card, it is most likely for security reasons

– Security engineering will consume most of your time

Security is complex


Some References

The reference from Oracle

– www.oracle.com/technetwork/java/javame/javacard/

A tutorial with the rest of today’s example

– javacard.vetilles.com/tutorial/

GlobalPlatform’s Web site

– www.globalplatform.org

Getting started

http://www.oracle.com/technetwork/java/javame/javacard/

http://javacard.vetilles.com/tutorial/

http://www.globalplatform.org/


Graphic Section Divider


Technology

First Steps with Java Card