JavaCard. Java Card - old vs new

Transcription

1 JavaCard 1 Old Smart Cards: One program (applet) Written in machine-code, specific to chip Burned into ROM Java Card - old vs new old vs new smartcards New Smart Cards: Applet written in high-level language (mainly Java Card) Compiled into bytecode Stored in EEPROM Interpreted on card Multi-application:several applets on one card Post-issuance: adding or deleting applets on card 2

2 How Java and smart cards mix Java Card is a stripped down version of Java for smart cards up to version 2.1 (and security is improving) one major vendor behind Java Card is Visa Java Card makes multi-application cards based on a common platform possible Opens smart card development Uses a known programming language (re)use of standard SW development tool e.g. JBuilder 3 How can Java fit on a card? Supported Java Features packages dynamic object creation virtual methods interfaces exceptions Unsupported Java Features dynamic class loading security manager threading object cloning garbage collection large data types 4

3 Multi-application cards Multi-application cards are an important goal getting more developers on board is essential Multiple applets can execute on a card credit, debit, e-cash, loyalty programs Explicit and covert channels between applets must be eliminated software risk management 5 Java Card security!= Java security Good no dynamic class loading only one active applet no threading objects include rudimentary access control Bad native method calls no garbage collection In some smart cards object sharing complexity out of band verification 6

4 Security risks in Java Card 2.1 protocol interactions sharing secrets between applications introduces new problems security is hard linking, export, CAP files native methods verification object sharing multi-application risks applets MUST behave the usual suspects apply physical attacks side-channel monitoring (e.g. DPA) the terminal problem 7 Multi-application issues Secure Features: no dynamic class loading reduces threat of malicious applets no multi-threading non-interference applet firewalls prevents referencing another applet s objects Risks & Assumptions trust-based applet model assume applets are non-malicious security testing needed JCRE must be perfect 8

5 Security is harder than it sounds Java Card is not truly cross platform byte code CAP export files linking problems no strings, thus tables code verification? before conversion exception handling Other problems: native methods INT? (32 bits) applet testing and debugging issues sharing methods among applets (difficult) ISO 7816 APDU problems hostile applets denial of service 9 Java Card - Security What to do? Assume the platform is secure it is getting better Applets must be carefully designed and implemented Testing applets for security is essential Java Card Security = platform + applets 10

6 Java Card - Development steps 11 Java Card - Programming Dialect of Java for programming smartcards Subset of Java (due to hardware constraints) no threads, doubles, strings, garbage collection, and very restricted API With some extras (due to hardware peculiarities) persistent & transient data in EEPROM & RAM transaction mechanism Java Card applets are executed in a sandbox, like applets in a web browser. (In fact, Java Card sandbox rules are more restrictive than Java s)» In some smart cards 12

7 Java Card - Programming The Java Card language JC is a subset of the Java language: no reals, doubles, strings, multi-dim arrays no threads JC uses 16 bit arithmetic, not 32. JC uses an optimized form of class files, called CAP-files. The Java Card API: a subset of Java s API no need for most standard I/O classes plus some extras for smartcard I/O with APDUs using ISO 7816 persistent and transient data transactions 13 Java Card - Programming Java Card API packages: java.lang Object, Exception,... javacard.framework ISO7816, APDU, Applet, JCSystem javacard.security KeyBuilder, RSAPrivateKey, CryptoException javacardx.crypto Cipher More API s: Global Platform addition to the Java Card API to support downloading of (digitally signed) applets onto a card Open Card Framework (OCF) API for building terminal applications 14

8 16 bit arithmetic: JC code contains many(short)casts. In particular, all intermediate results (which are of type int) must be cast to short Example: short s; byte b; Java Card - Programming s = b+s+1; // not ok, compiler complains s = (short)(b+s+1); // not ok, converter complains s = (short)(b+(short)(s+1)) // ok 15 Java Card - Architecture applet applet applet Java Card Java Card API Java Card platform Virtual Machine (mini OS) smartcard hardware 17

9 Java Card - I/O with APDUs applet applet applet Java Card platform smartcard hardware OS selects command applet Applet APDU, and incl. invokes applet sends applet its response ID process executes APDU method terminal 18 Java Card - Memory ROM program code of VM, API, and pre-installed applets EEPROM persistent storage of the data, incl. objects with their fields, and program code of downloaded applets is persistent, and is kept when power is lost RAM transient storage of data is transient, and is lost as soon as power is lost 19

10 Java Card - Memory Smart Card power supply: the power supply of a smartcard can be interrupted at any moment, by a so-called card tear to cope with this, the API offers support for: Persistent or transient allocation of fields Transactions Persistent vs transient data: By default, fields of Java Card objects are stored in EEPROM The API offers methods that allow fields that are arrays to be allocated in RAM This has performance advantages, and it can be useful that fields are automatically reset when power fails 20 Java Card - Memory Why use transient arrays? scratchpad memory RAM is faster & consumes less power EEPROM has limited lifetime automatic clearing of transient array on power-down, and on card reset or applet selection can be useful! 21

11 Java Card - Memory Persistent vs transient data - example: public class MyApplet { byte[] t, p; short balance; SomeObject o; // persistent array p and persistent object o p = new byte[128]; o = new SomeObject(); // transient array t t = JCSystem.makeTransientByteArray((short)128, JCSystem.CLEAR_ON_RESET); 22 Java Card - Memory Transient array - example: public class MyApplet { boolean keysloaded, blocked; // persistent state private RSAprivateKey priv; //@ invariant keysloaded ==> priv!= null; byte[] protocolstate; // transient session state... protocolstate = JCSystem.makeTransientByteArray((short)1, JCSystem.CLEAR_ON_RESET); // automatically reset to 0 when card starts up... 23

12 Java Card - Memory Transactions: The API offers methods to join several assignments to fields into one atomic action ie. atomic update of the EEPROM, called a transaction.» If the power supply stops halfway during a transaction, all assignments of that transaction are rolled back/undone. private int balance; private int[] log; //@ invariant (* log[n] is previous balance *);... what if a card tear // update log n++; log[n] = balance; occurs here? balance = balance amount; // update balance 24 Java Card - Memory Transactions example: private int balance; private int[] log; //@ invariant (* log[n] is previous balance *);... JCSystem.beginTransaction(); // update log n++; log[n] = balance; // update balance balance = balance amount; JCSystem.endTransaction(); 25

13 JavaCard - VM The Java Card Virtual Machine (JCVM): specification defines: subset of the Java programming language Java-compatible VM for smart cards include:» binary data representations and file formats» JCVM instruction set JCVM familiar features include: Objects, Inheritance, packages, dynamic object creation, virtual methods, interfaces, and exceptions. 26 JavaCard - VM constraints Packages A package can refer to up to 128 other packages A fully qualified package name is limited to 255 bytes. Note that the character size depends on the character encoding. A package can have up to 255 classes. Classes A class can directly or indirectly implement up to 15 interfaces. An interface can inherit from up to 14 interfaces. A package can have up to 256 static methods if it contains applets (an applet package), or 255 if it doesn't (a library package). A class can implement up to 128 public or protected instance methods, and up to 128 with package visibility. 27

14 Java Card - Language limitations Language Features Keywords Types, Classes, and Interfaces Exceptions No support for: dynamic class loading, security manager (java.lang.securitymanager), threads, object cloning, and certain aspects of package access control are not supported. No support for: native, synchronized, transient, volatile, strictfp are not supported. No support for: char, double, float, and long, or for multidimensional arrays. Support for int is optional. Some Exception and Error subclasses are omitted because the exceptions and errors they encapsulate cannot arise in the Java Card platform. 28 Java Card - Message-Passing model Processing APDUs Every time there is an incoming APDU for a selected applet: The JCRE invokes the applet's process() method The incoming APDU is passed as an argument The applet must: parse the command APDU process the data generate a response APDU and return control to the JCRE 29

15 Java Card - Message-Passing model 30 Java Card - Application components Java Card application comprises: The back-end application: Using the card The host application: Accessing the applets on the smart card The terminal: Physical interface with the card The Java Card: Java Card framework Java Card applet 31

16 Java Card - Application components Inside the Java Card: Card s operating System JCRE - Java Card Runtime Environment Java Card Virtual Machine Java Card Framework and APIs One or more Java Applets 32 Java Card - Applet methods 33

17 Java Card - Applet life-cycle 34 Java Card - Creating an Applet All Java Card applets extend the Applet base class and must implement the install() and process() methods JCRE calls install() when installing the applet, and process() every time there is an incoming APDU for the applet Developing a Java Card Applet: 1. Write the Java source 2. Compile your source 3. Convert the class files into a CAP (Converted Applet) file (binary representation of classes and interfaces) 4. Verify that the CAP is valid (structure, valid bytecode subset, interpackage dependencies) 5. Install the CAP file 35

18 Java Card - Creating an Applet Applet Structure: import javacard.framework.*... public class MyApplet extends Applet { // Definitions of APDU-related instruction codes... MyApplet() {...} // Constructor // Life-cycle methods install() {...} select() {...} process() {...} deselect() {...} // Private methods... } 36 Java Card - Applet Methods install() called when a new applet is being installed public static void install ( byte[] barray, short boffset,byte blength){ new myapplet(null); } Must call register() to let JCRE know that a new applet has been installed select() when we want to use an applet is called when SELECT APDU is received 37

19 Java Card - Applet Methods process() when an APDU is received and applet is selected its method process is called to process the APDU the selected applet parses the APDU and perform whatever it needs to perform normally the body of process() method is a big switch with code for each INS (APDU field) value defined deselect() is called when another SELECT APDU is received 38 Java Card - Object Sharing Shareable interface enable object sharing between applets Shareable Interface Object (SIO) An object of a class that implements a shareable interface is called a SIO To the owning context, an SIO is a normal object To any other context, the SIO is an instance of the shareable interface type only the methods defined in the shareable interface are accessible» Field and methods of the SIO are protected by the firewall 41

20 Java Card - Applet Firewall The applet firewall partitions the Java Card object system into separate protected object spaces called context JCRE context Firewall Group context Applet context Applet context Group context Applet context 42 Java Card - Applet Firewall JCRE assigns a context to a created applet instance All applet instances of a single Java package share the same (group) context No firewall between applet instances in the same group context Each new created object is assigned an owning context The JCRE maintain its own JCER context JCRE context has special privileges: the JCRE context has access to any applet s context There is only one active context at any given time either the JCRE context or an applet s group context 43

21 Java Card - Applet Firewall Sharing mechanisms are accomplished by the following means: JCRE privileges The JCRE is able to invoke other applets methods» i.e. select, deselect, process,... JCRE entry point objects Identical to system calls» i.e. APDU object Global arrays Special type of JCRE entry point object» i.e. APDU buffer Shareable interfaces» Shareable Interface Object (SIO) 44 Java Card - Object Sharing Shareable interface Server creates a Shareable Interface Object Define a shareable interface Package com.fasttravel.airmiles; import javacard.framework.shareable; Public interface AirMilesInterface extends Shareable{ public void grantmiles(short amout); } 45

22 Java Card - Object Sharing Create a Shareable Interface Object Create a service provider class, implementing the sharable interface creates one or more objects of the service provider class Package com.fasttravel.airmiles; import javacard.framework.shareable; public class AirMilesApp extends Applet implements AirMilesInterface { private short miles; } public void grantmiles(short amout) { miles = (short)(miles + amout);} 46 Java Card - Object Sharing Requesting a SIO Client applet lookups the server AID: public static AID lookupaid( byte[] buffer, short offset, byte length) Client applet gets the server SIO: public static Shareable getappletshareableinterfaceobject( AID server_aid, byte parameter) JCRE invokes the Server applet: Public Shareable getshareableinterfaceobject( AID client_aid, byte parameter) 47

23 Java Card - Object Sharing Server s Shareable Interface Object public class AirMilesApp extends Applet implements AirMilesInterface { short miles; public Shareable getshareableinterfaceobject( AID client_aid, byte parameter){ //authenticate the client //... explained later... } return this; //Return the SIO } public void grantmiles(short amout){ miles = (short)(miles + amout); } 48 Java Card - Object Sharing Shareable Interface Object - Usage 49

24 Java Card - Object Sharing Shareable Interface Object - Invocation Package com.smartbank.wallet; import javacard.framework.*; import com.fasttravel.airmiles,airmilesinterface; public class WalletApp extends Applet { private byte[] air_mailes_aid = SERVER_AID_BYTES; //... Applets code... public void requestmiles(short amout){ AID AirMiles_aid = JCSystem.lookupAID( air_mailes_aid, 0, air_mailes_aid.length); AirMilesInterface sio = (AirMilesInterface) JCSystem.getAppletShareableInterfaceObject( AirMiles_aid, SECRET); } } if (sio == null) ISOException.throwIt(SW_FAILED_TO_OBTAIN_SIO) sio.grantmiles(amount); 50 Java Card - Object Sharing Authenticate a Client Applet when returning the SIO: public class AirMilesApp extends Applet implements AirMilesInterface { public Shareable getshareableinterfaceobject( AID client_aid, byte parameter){ if (client_aid.equals(wallet_app_aid_bytes, (short)0, (byte)wallet_app_aid_bytes.length)) == false) return null; if (parameter!= SECRET) return null; return (this); } 51

25 Java Card - Object Sharing Authenticate a Client Applet when being called: Other contexts may have obtained the SIO reference!» Verify every time the SIO is invoked public void grantmiles (short amount) { AID client_aid = JCSystem.getPreviousCOntextAID(); if (client_aid.equals(wallet_app_aid_bytes, (short)0, (byte)wallet_app_aid_bytes.length)) == false) ISOException.throwIt(SW_UNAUTHORIZED-CLIENT); //... Performs the methods computation miles = (short)(miles + amount); } 52 Java Card - Context Switch Context switches occur during invocation, return, and exception exits from instance methods of an object owned by a differentcontext when a sharing mechanism is applied the Java Card virtual machine enables access by performing a context switch On card reset, the JCRE context is always the active context During a context-switching method invocation, the current context is saved, and the new context becomes the active context 53

26 JavaCard - Security risks Protocol interaction risks: Unintended protocol interactions pose risks: different protocols share same key material observation of protocol P can be used against Q Shared key material is motivated by: digital certificates for multi-applications small memory for public/private key pairs crypto APIs 54 JavaCard - Security risks The terminal problem: No trusted interface for interacting with users A common solution is to use PCs but PCs are easily hacked Windows/Linux are inherently insecure! Some suggestions: smart phones/pdas» Are these really secure!?! simple dedicated devices Maybe in the Future: On the card itself!!! 55

27 JavaCard - Security risks Physical attacks still apply: Physical attacks attempt to reverse engineer the card or monitor a running card to obtain card secrets differential power analysis (Kocher) no card is 100% tamper proof (Anderson & Kuhn) Cards often include secrets from there owners» e.g.: PayTV Some secrets could be used to add functionality and/or add value Cost of hacking the card must be greater than the return on the investment 56 Acknowledgments Erik University of Nijmegen C. Enrique java.sun.com/javacard/ Raman University of Illinois Fu-Chiung Tatung University 57