68
MESURE Project Fonctionalities (Rapport sur les fonctionnalités essentielles à mesurer) Emission Date October 2007 Project name MESURE Document type Technical report Ref & Version F2.1-1.0 Classification Public Number of pages 68

Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

MESURE Project

Fonctionalities(Rapport sur les fonctionnalités essentielles à mesurer)

Emission Date October 2007

Project name MESURE

Document type Technical report

Ref & Version F2.1-1.0

Classification Public

Number of pages 68

Page 2: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

DOCUMENTATION LICENSE AGREEMENT

READ THE TERMS OF THIS AGREEMENT CAREFULLY BEFORE OPENING THE DOCUMENTATION MEDIA PACKAGE, OR DOWNLOADING THE DOCUMENTATION. BY OPENING THE DOCUMENTATION MEDIA PACKAGE, OR DOWNLOADING THE DOCUMENTATION YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE DOCUMENTATION ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "I AGREE" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED DOCUMENTATION OR, IF THE DOCUMENTATION IS ACCESSED ELECTRONICALLY, SELECT THE "I DECLINE" BUTTON AT THE END OF THIS AGREEMENT.

1. DEFINITIONS

Derivative Work: any work based upon the Documentation or upon the Documentation and other pre-existing works, such as translation, adaptation, modification, transformation, integration, etc.

Documentation: any report produced for the MESURE project.

Execution Date: date of receipt of the Documentation by Licensee.

License: this documentation license agreement.

Licensee: You

Licensors: MESURE partners (CNAM/Cedric, POPS CNRS/INRIA/USTL and Trusted Logic S.A.).

2. License

(i) Subject to the terms and conditions of this License, Licensors hereby grant Licensee, to the extent of Licensors’ intellectual proprietary rights in the Documentation, a worldwide, royalty-free, non-exclusive license to exercise the rights in the Documentation as stated below:a. To consult the Documentation.b. To modify the Documentation to create Derivative Works.c. To copy and distribute the Documentation and Derivative Works created by Licensee.

(ii) The rights granted in Article 2(i) may be exercised in all media and formats whether now known or hereafter devised.

3. Restrictions

(i) The rights granted under Article 2(i) are for non commercial use only. Licensee may not exercise any of the rights granted under Article 2(i) in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation.

(ii) Licensee may distribute the Documentation and Derivative Works only under the terms of this License. Licensee must include a copy of this License, or a valid Uniform Resource Location for this License, with every copy of the Documentation or Derivative Work distributed by Licensee. Licensee may not offer or impose any terms on the Documentation or Derivative Works that alter or restrict the terms of this License or the recipient’s exercise of the rights granted hereunder. Licensee must keep intact, inter alia, the disclaimer of warranties.

(iii) Licensee must notify Licensors of any Derivative Work created by Licensee and make such Derivative Work available to Licensors and any third party under the terms of this License.

4. INTELLECTUAL PROPERTY RIGHTS

©Mesure Project, 2006-2007 page 2/68

Page 3: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

(i) The Documentation and all associated intellectual property rights shall remain the exclusive property of Licensors. Licensors remains free to use, modify, integrate, distribute and license the Documentation and Derivative Work for any purpose, including commercial, and license the Documentation and Derivative Work to third parties under any license agreement. Licensors does not commit to provide any maintenance, error correction or support on the Documentation or to make future versions of the Documentation or Derivative Work created by Licensors available to Licensee or any third party.

(ii) Licensee may not remove or obscure any copyright notice or trademark notice of Licensors or third parties contained in the Documentation.

(iii) Licensee is granted no right or title in the Documentation or Derivative Work other than the rights set forth in Article 2 of this License.

5. Disclaimer of Warranty

The Documentation is provided to Licensee “as is”. Except to the extent that these disclaimers are held to be legally invalid, Licensors make no representations or warranties of any kind concerning the Documentation, express, implied, statutory or otherwise, including, without limitation, warranties of accuracy, completeness, merchantability, fitness for a particular purpose, non-infringement, or the absence of latent or other defects, or the presence of errors, whether or not discoverable.

6. LIABILITY

(i) To the extent not prohibited by law, in no event will Licensors or their licensors be liable to Licensee for any lost revenue, profit or data, or for special, indirect, consequential, incidental or punitive or exemplary damages, however caused regardless of the theory of liability, arising out or related to the use of or inability to use the Documentation, even if Licensors have been advised of the possibility of such damages.

(ii) The limitations of damages and liability set forth in this License are fundamental elements of this License. The parties acknowledge and agree that neither would be able to perform hereunder on an economic basis without such limitations.

7. INFRINGEMENT

(i) In the event Licensee becomes aware of any claim or assertion that the Documentation might infringe a third party’s intellectual property rights, Licensee shall immediately inform Licensors of such claim or assertion. Upon Licensors’ request, Licensee shall then immediately cease using the Documentation and comply with Article 8(iii) of this License.

(ii) Should the Documentation be declared infringing in court, or in Licensors’ reasonable opinion, be likely to become the subject of a valid claim of infringement of any intellectual property rights associated with the Documentation, Licensors shall, at their sole option, either (i) modify the Documentation so that it is no longer infringing, or (ii) notify Licensee in writing that the first option is not reasonably possible and terminate this License without any delay or compensation.

8. Term and Termination

(i) The term of this License shall begin on the Execution Date and expire with the expiration of the applicable copyright on the Documentation.

(ii) Licensors may terminate this License as set forth in Article 7 or upon any breach of this License by Licensee.

(iii) Upon termination of this License, Licensee shall cease any further use of the Documentation, return to Licensors all copies of the Documentation in any form in Licensee’s possession or control, including storage media like e.g. floppy disks, CD-ROMS,

©Mesure Project, 2006-2007 page 3/68

Page 4: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

etc and permanently de-install or destroy the Documentation installed on any Licensee computer or storage device. Licensee shall certify in writing upon first request from Licensors that these measures have been carried out.

(iv) Articles 1, 4, 5, 6, 8, 9, 10, 11 and 12 shall survive termination or expiration of this License.

9. Severability

If any term or provision of this License should be declared invalid or unenforceable by a court of competent jurisdiction or by operation of law, the provision is to that extent to be deemed omitted, and the remaining provisions shall not be affected in any way. The invalid term or provision shall be replaced by such valid term or provision as comes closest to the intention underlying the invalid term or provision.

10.Waiver

The delay or failure of either party to exercise in any respect any rights or remedies provided for in this License shall not be deemed a waiver of that right or remedy nor shall any single or partial exercise of any right or remedy preclude the further exercise of that right or remedy or of any other right or remedy under this License.

11.Governing Law

The governing law is the law of France. All disputes arising out of or in connection with this License, including any question regarding its existence, validity or termination, shall be finally settled by arbitration under the Rules of arbitration of the “International Chamber of Commerce” by one arbitrator in accordance with the said Rules. Arbitration shall take place in Paris, France. The language to be used in the arbitration proceeding shall be French.12.Notices

Any notice under this License shall be delivered either by letter to the address of the party concerned or by e-mail to its e-mail address. For inquiries, please contact:

• CNAM, 292 rue Saint Martin, 75141 Paris Cedex 3, France,

• or INRIA Futurs, POPS research group, Bât. M3, Cité Scientifique, 59655 Villeneuve d'Ascq Cedex, France,

• or Trusted Logic, 5 rue du Bailliage, 78000 Versailles, France.

©Mesure Project, 2006-2007 page 4/68

Page 5: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

Table of Contents

1 INTRODUCTION ................................................................................................. 6

2 EXCLUDED FEATURES ........................................................................................... 7

2.1 The installation and personalization phases ..................................... 7

2.2 The Java Card API v2.2 ...................................................................... 8

2.3 The error paths .................................................................................. 8

2.4 The input/output (I/O) ..................................................................... 9

2.5 Unsupported features ....................................................................... 9

2.6 Unused features .............................................................................. 10

3 INCLUDED FEATURES ........................................................................................ 14

3.1 Java Card API .................................................................................. 143.1.1 API sensitive classes ................................................................................... 143.1.2 Utilities ...................................................................................................... 24

3.2 Java Card VM ................................................................................... 30

4 REFERENCES .................................................................................................. 48

5 ANNEX 1 – STATISTICS FOR JAVAPURSE APPLICATION (SUN) ....................................... 49

6 ANNEX 2 – STATISTICS FOR BANKING APPLICATION 1 ................................................ 52

7 ANNEX 3 – STATISTICS FOR BANKING APPLICATION 2 ................................................ 57

8 ANNEX 4 – STATISTICS FOR TRANSPORT APPLICATION ................................................. 61

9 ANNEX 5 – STATISTICS FOR CARDEDGE APPLICATION (MUSCLECARD) ............................ 64

©Mesure Project, 2006-2007 page 5/68

Page 6: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

1 Introduction

The objective of the MESURE project is to define a reference for measuring the characteristics of Java Card platforms, and more specifically their performances. The results of the project should as much as possible be applicable to all industrial domains in which the Java Card technology is or will be used.

The difficulty of a project like MESURE is to define a set of measurements that makes sense for all industries. The report [F1.2REQ] has established a list of the requirements of the various industries in measure of the performances.

This report has also defined a first subset. The SIM Toolkit API was left aside because this API needs a particular process of load, what would have increase significantly the complexity. Furthermore, there is no reference application using SIM Toolkit API on the market. Thus, the present report concentrates on the Java Card API and the Global Platform API, without forgetting naturally to be interested in the Java Card RE and in the Java Card VM.

Some constraints apply to the MESURE project, and in particular time constraints, and it is not possible to envisage measuring in a exhaustive way the performances of all the Java Card platforms. As a consequence, it is necessary to give a minimal list of the essential features to be measured.

It is the purpose of this document, which begins on the one hand with highlighting some points that will not be covered by the MESURE project, after having clarified why they are not essential, and on the other hand with detailing the main objectives for the remaining features.

©Mesure Project, 2006-2007 page 6/68

Page 7: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

2 Excluded features

This chapter deals with functionalities that have not been measured.

The reasons that have motivated their exclusion from the set of performed measures will be detailed in this chapter.

2.1 The installation and personalization phasesIt is necessary to distinguish some phases in the lifecycle of a Java Card application :

● The installation of the application.Each Java Card application needs to defined a specific installation method. When run, this method allocates an instance of the applet class, initializes it, and registers it to the Java Card RE. The initialization usually involves the installation and initialization of other objects. Once initialized and duly registered, an application instance is ready for accepting incoming commands. The Java Card RE may then select the instance and forward to it APDU commands to be processed.

● The personalization of the application.Then, Java Card applications needs to be personalized. More precisely, they are populated with all necessary elements (e.g. keys, personalization data) to function normally.

● The normal use of the application.Once personalized, the Java Card applications can then be used normally by any cardholder.

● The deletion of the application.At any time, the Java Card applications may be deleted. There are unregistered and cannot be selected any longer.

Only features related to the normal use phase of Java Card applications will be considered here. Measures of performances when installing, personalizing or deleting an application, are of lesser importance from user's point of view. Moreover, these management operations are only performed once.

As required by good usage guides, such as [SDG], the allocation of objects (including transient objects) shall be performed during the installation phase of the applications. This is particularly important because memory (and in particular RAM) is often a scarce resource on smart cards. For applications that are personalized in the factory (before issuance), it may be acceptable to perform such allocation during the personalization phase.

As explained before, features related to the installation and personalization phases will not be measured during the project, and as a consequence, the new, newarray and anewarray bytecodes, the constructors of the Java Card API, as well as the following methods are not considered here:

● JCSystem.makeTransientXXXArray methods, which are dedicated to the allocation of transient arrays,

● KeyBuilder.buildKey, which is used to allocate keys,● getInstance methods whose purpose is to allocate cryptographic engines.● Applet.register(), Applet.register(byte[],short,byte).

©Mesure Project, 2006-2007 page 7/68

Page 8: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

In the same manner, and as detailed in [F1.2REQ], the GlobalPlatform usage of the secure channels is generally restricted to the personalization phase and as a consequence the functionalities offered by the SecureChannel class are excluded.

2.2 The Java Card API v2.2At the moment, the majority of the deployed cards always implement the revision 2.1 of the Java Card specification. That is why the MESURE project is not going to deal firstly with the Java Card API v2.2. Nevertheless, if there is enough time at the end of the project, some important features proposed in this version of the specification, and which are listed below, will be taken into account:

● Checksum. This class is sometimes used to check integrity of the most sensitive data of applications.

● APDU.getCurrentBuffer, APDU.getCurrentAPDUBuffer. These methods may be used to avoid passing the APDU buffer as argument of methods and simplify the code of applications.

2.3 The error pathsDuring normal use phase of an application, two types of execution paths have to be distinguished:

● The success paths.These paths lead to a success during execution. For example, when using a credit card, a success path is defined by inserting the card, entering the correct PIN code, performing a banking operation (such as consulting the balance or take some money...), and getting back the card.

● The failure paths. These paths are those which are related to a bad usage of an application. For example, the fact to enter a bad PIN code is considered as being a failure path.

For the MESURE project, we will focus on success paths, because performances are of lesser importance in case of failure. Moreover, the failure paths are rarely reached.

As a consequence, the failure cases for the comparison methods of the Java Card API (OwnerPIN.check with a bad PIN as parameter, AID.XXXEquals with a bad AID as parameter, Util.arrayCompare with different arrays as parameters...), as well as the methods invoked in case of failure detection (e.g. the methods used to react to integrity failures, such as GPSystem.lockCard, GPSystem.terminateCard...), will not be measured. In the same manner, the Exception class and its subclasses and the athrow bytecode will be discarded.

For a more complete list, refer to [F1.2REQ] which highlights measurements whose frequency is labeled “Failure”.

©Mesure Project, 2006-2007 page 8/68

Page 9: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

2.4 The input/output (I/O)The purpose of the MESURE project is to supply a set of tests to benchmark Java Card platforms available for anybody and supported by any card reader. The various tests thus have to return accurate results, even if they are not executed on precision readers. The MESURE project reach this goal, and remove the potential card reader weakness (in terms of delay, variance and predictability) by controlling the noise generated by measurement equipment (the card reader and the workstation). Removing the noise added to a specific measurement can be done with the computation of an average value extracted from multiple samples. As a consequence, it is important on the one hand to perform each test several times and to use basic statistical calculations (mean, variance, deviation...) to filter the trustworthy results. On the other hand, it is necessary to execute several times in each test the operation to be measured in order to fix a minimal duration for the tests (> 1 second) and to expect getting precise results.

Concerning the I/Os their measurability raises some problems:

● The size of the data transmission is limited (255 bytes on a T=0 protocol) and it is not enough to remove measure uncertainty on the time spend to transmit a byte.

● According to the smart card/card reader pair, the I/O benchmark provides different measures.

● Each part of an APDU is managed differently on a smart card reader. The 5 bytes header is read first, and the following data can be transmitted in several way: 1 acknowledge for each byte or not, delay or not before noticing the status word…

● The smart card driver used by the workstation generally induces more delay on the measurement than the smart card reader itself. Measurements of the same card, with the same reader, are not the same when done on a Windows workstation and on a Linux workstation for example. It is also different between a Windows XP and a Windows Vista...

Thus, there is no way to bench the smart card I/Os without knowledge about the smart card reader, statistical calculations are not helpful here, and the only way to measure the I/Os consist in using precision readers, available but not essential for other measurements. For all these reasons, the final note of the benchmark will not take care of these I/O measurements, but a few assertions will be made on them. Indeed, the theoretical transfer time may be asserted with the theoretical transfer rate returned in the ATR as specified by the ISO 7816 standards.

2.5 Unsupported features A majority of the Java Card platforms deployed do not support 32-bit instructions. For that reason, the MESURE project will not include any test concerning the related bytecodes. These bytecodes are exhaustively listed below:

● Array manipulation: iaload, iastore● Global variable access: getfield_i, getfield_i_this, getfield_i_w,

getstatic_i, putfield_i, putfield_i_this, putfield_i_w, putstatic_i● Local variable access: iload_<n>, iload, istore_<n>, istore● Local variable incrementation: iinc, iinc_w● Constant handling: iconst_<n>, bipush, sipush, iipush● Arithmetic: iadd, isub, imul, idiv, irem, ineg, ishl, ishr, iushr, ior, iand,

ixor

©Mesure Project, 2006-2007 page 9/68

Page 10: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

● Comparison: icmp● Branching: ilookupswitch, itableswitch● Types conversion: i2b,i2s, s2i● Return instructions: ireturn● Stack instructions: pop2

Moreover, the features marked as "deprecated" in the Java Card API are not taken into account in the MESURE project. It is the case of the ALG_RSA_ISO9796 cryptographic algorithm available in the Cipher class. In the same manner, the keys and algorithms that are rarely supported by Java Card platforms are not a priority. Here is a list of these cryptographic objects:

● Keys implementing the javacardx.crypto.KeyEncryption interface (i.e. if the KeyBuilder.buildKey method is invoked with the keyEncryption parameter set to true).

● DSA keys.● RSA keys whose length is different from 512, 768, 1024 or 2048 bits.● Key pairs (KeyPair class).● Engines for RIPE MD-160 message digests (i.e. if the

MessageDigest.getInstance method is respectively invoked with the algorithm parameter set to ALG_RIPEMD160).

● Engines for DES-based MAC4 signatures (i.e. if the Signature.getInstance method is invoked with the algorithm parameter set to ALG_DES_MAC4_XXX).

● Engines for DES-based MAC8 signatures using PKCS5 padding (i.e. if the Signature.getInstance method is invoked with the algorithm parameter set to ALG_DES_MAC8_PKCS5).

● Engines for DSA-based signatures (i.e. if the Signature.getInstance method is invoked with the algorithm parameter set to ALG_DSA_SHA).

● Engines for RSA-based signatures using RIPE MD-160 message digests (i.e. if the Signature.getInstance method is invoked with the algorithm parameter set to ALG_RSA_RIPEMD160_XXX).

● Engines for RSA-based signatures using RFC 2409 padding (i.e. if the Signature.getInstance method is invoked with the algorithm parameter set to ALG_RSA_XXX_RFC2409).

● Engines for DES-based ciphers using PKCS5 padding (i.e. if the Cipher.getInstance method is invoked with the algorithm parameter set to ALG_DES_XXX_PKCS5).

● Engines for RSA-based ciphers using ISO 17888 padding (i.e. if the Cipher.getInstance method is invoked with the algorithm parameter set to ALG_RSA_ISO14888).

2.6 Unused featuresThe following types of applications, defined in [F1.2REQ], have been chosen to define application profiles, because they are certainly the most representative among the deployed applications: banking applications, identity applications and transport applications.

©Mesure Project, 2006-2007 page 10/68

Page 11: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

For each profile, standard scenarios have been analyzed. More precisely, a typical scenario is a script of commands, all related to the standard use phase of the profiled application, and all leading to a success path (See [F2.2MET] for details concerning the methodology and the obtained results). By the way, features that are never or exceptionally used have been detected and are listed below:

● DES keys of CLEAR ON RESET duration. Keys are either master keys of persistent duration or session keys of CLEAR ON DESELECT duration.

● Engines for MD5 message digests (i.e. if the MessageDigest.getInstance method is respectively invoked with the algorithm parameter set to ALG_MD5). For security reasons, the applications prefer using SHA-1 message digests.

● Engines for RSA-based signatures using MD5 message digests (i.e. if the Signature.getInstance method is invoked with the algorithm parameter set to ALG_RSA_MD5_XXX).

● Engines for pseudo random number generation (i.e. if the RandomData.getInstance method is respectively invoked with the algorithm parameter set to ALG_PSEUDO_RANDOM). For security reasons, the applications prefer using secure random number generators.

● RandomData.setSeed. This method is only useful for pseudo random number generators.

● getAlgorithm methods, getLength methods, Key.getSize, Key.getType, Key.isInitialized. The information returned by these methods are generally implicitely known by applications.

● getExponent, getModulus, getDP1, getDQ1, getP, getPQ, getQ methods. These methods return parts of the keys in plain text, and for security reasons the applications don't invoke them.

● Cipher.update, MessageDigest.update, Signature.update. It is often possible to prepare the data to be enciphered, signed or hashed in an array before to start the cryptographic computation, and the doFinal methods are generally used directly.

● MessageDigest.reset. The applications generally don't require this method because this cryptographic object is reset to its initial state after each call to the MessageDigest.doFinal method.

● Object.equals. The applications rarely need to compare references for equality.● AID.getBytes, AID.equals(Object), AID.equals(byte[],short,byte),

AID.partialEquals, AID.RIDEquals, JCSystem.getAID, JCSystem.getPreviousContextAID, JCSystem.lookupAID, JCSystem.getAppletShareableInterfaceObject. These methods are useful in a context of sharing (in order to get shareable references from the server, identify the client...), but for security reasons this mechanism is rarely used by applications.

● APDU.waitExtension. Java Card platforms generally use an automatic timer mechanism, and in this case this method may do nothing. As a consequence, this method is rarely invoked by applications.

● APDU.getInBlockSize, APDU.getOutBlockSize, APDU.getNAD. These methods are only useful in T=1 protocol and the provided information is rarely needed by applications. More precisely, getOutBlockSize returns 254 on payment cards, as specified for the IFSD (information field size for the terminal) in [EMV_BOOK1],

©Mesure Project, 2006-2007 page 11/68

Page 12: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

and getInBlockSize returns an IFSC (information field size for the ICC) depending on the APDU buffer length.

● APDU.receiveBytes. All the incoming bytes generally fit in the APDU buffer when invoking the APDU.setIncomingAndReceive method, and as a consequence receiveBytes is rarely called.

● APDU.setOutgoingNoChaining. The applications all use the APDU.setOutgoing method instead.

● JCSystem.abortTransaction. There is no reason to abort a transaction: all decisions are taken by applications before starting the transaction.

● JCSystem.getMaxCommitCapacity, JCSystem.getUnusedCommitCapacity. The values returned by these methods are only considered as being indicative.

● JCSystem.getTransactionDepth. No other method than the JCSystem.XXXTransaction dedicated methods can initiate or terminate a transaction. As a consequence, the transaction flow and the current transaction nesting depth level are implicitely known.

● JCSystem.getVersion. The version of the Java Card API on the targetted platforms is implicitely known and is determined by the version of the export files used when converting the applications.

● JCSystem.isTransient. The applications implicitely know the type of the arrays they use.

● OwnerPIN.getValidatedFlag, OwnerPIN.setValidatedFlag. These methods are protected and applications don't subclass the OwnerPIN class.

● OwnerPIN.update. The PIN is not updated during standard transactions; this method is generally invoked when processing personalization commands or issuer script commands.

In parallel, when analyzing the bytecodes used in standard applications, it appears that "wide" bytecodes are not commonly used, and as a consequence implementing related tests is not a priority. Those bytecodes are listed below:

● Global variable access: getfield_a_w, getfield_b_w, getfield_i_w, getfield_s_w, putfield_a_w, putfield_b_w, putfield_i_w, putfield_s_w

● Local variable incrementation: sinc_w, iinc_w● Simple condition: ifeq_w, ifge_w, ifgt_w, ifle_w, iflt_w, ifne_w,

ifnonnull_w, ifnull_w● Complex condition: if_acmpeq_w, if_acmpne_w, if_scmpeq_w, if_scmpge_w,

if_scmpgt_w, if_scmple_w, if_scmplt_w, if_scmpne_w● Branching: goto_w

Beyond that, the following bytecodes are not commonly used during the normal use phases of the applications:

aastore, anewarray, astore_0, athrow, bipush, getfield_a_w, getfield_b_w, getfield_i, getfield_i_this, getfield_i_w, getfield_s_w, getstatic_i, getstatic_s, i2b, i2s, iadd, iaload, iand, iastore, icmp, iconst_0, iconst_1, iconst_2, iconst_3, iconst_4, iconst_5, iconst_m1, idiv, if_acmpeq, if_acmpeq_w, if_acmpne_w, ifgt_w, ifle_w, ifnonnull_w, ifnull_w, if_scmpeq_w, if_scmpge_w, if_scmpgt_w, if_scmple_w, if_scmplt, if_scmplt_w, iinc, iinc_w, iipush, iload, iload_0, iload_1, iload_2, iload_3, ilookupswitch, imul, ineg, instanceof, ior, irem, ireturn, ishl, ishr, istore, istore_0, istore_1, istore_2, istore_3, isub, itableswitch, iushr, ixor, new, nop, pop2, putfield_a_this, putfield_a_w, putfield_b_this,

©Mesure Project, 2006-2007 page 12/68

Page 13: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

putfield_b_w, putfield_i, putfield_i_this, putfield_i_w, putfield_s_this, putfield_s_w, putstatic_b, putstatic_i, putstatic_s, s2i, sinc_w, sipush, sstore_0, sushr, swap_x.

On those 88 bytecodes, 52 deal with 32 bits integer. Supporting 32 bits integers is indeed optional in the Java Card specification, which makes it impossible to develop a widespread application that supports this feature.

21 of those 88 bytecodes deal with wide indexes (actually, three deal with both the 32 bits integers and the wide indexes).

The 18 remaining bytecodes are the following :aastore, anewarray, astore_0, getstatic_s, if_acmpeq, if_scmplt,

instanceof, new, nop, pop2, putfield_a_this, putfield_b_this, putfield_s_this, putstatic_b, putstatic_s, sstore_0, swap_x

Some of those are not used during the execution of an application because they imply using inefficiently the memory (aastore, anewarray, athrow, instanceof, new, putfield_a_this), which, on a smart card, could prove dramatic. Some other are scarcely generated at compilation time (if_acmpeq, if_scmplt, nop, pop2, swap_x).

Finally the remaining bytecode is athrow and it is clearly defined to be used when something exceptional appends!

©Mesure Project, 2006-2007 page 13/68

Page 14: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

3 Included features

This chapter details the features commonly used by applications and that have to be considered when measuring performances. These test objectives are classified into the following categories:

• The Java Card platform Application Programming Interface (Java Card API).The tests are here organized by class and method.

• The Java Card platform Runtime Environment (Java Card RE).

• The Java Card platform Virtual Machine (Java Card VM).The tests are organized by instruction.

3.1 Java Card APIThis section gives a detailed list of the classes and methods of the Java Card API that are often invoked by applications. For each method, the preconditions (ongoing transaction or not...), the parameters, their types and duration (standard or global, persistent or CLEAR ON DESELECT or CLEAR ON RESET...).

3.1.1 API sensitive classesLet's start with the sensitive classes. These classes require security mechanisms or cryptographic computations, in particular for integrity protection, which have a real impact on the performances.

javacard.framework.OwnerPINreferencePin An OwnerPin object

TEST checkThe normal use phase of applications often include a successful comparison of the PIN. The following formats may be used for the PIN:

• Format BCD. It includes only numerical digits, coded on a nibble, left justified, and eventually padded on the right with an 'F' nibble if the number of digits is odd:

'2' N P P P P P/'F' P/'F' P/'F' P/'F' P/'F' P/'F' P/'F' P/'F' 'F' 'F' where N is the PIN length, with permissible values of '4' to 'C' P is a PIN digit, with permissible values of '0' to '9'

• Format ASCII. It includes all displayable characters coded on one byte and left justified.

• Format hexadecimal. It includes all binary values coded on one byte.

©Mesure Project, 2006-2007 page 14/68

Page 15: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.OwnerPINTEST CASE 1

Preconditions

The PIN is coded in BCD format: referencePin has been updated with ['24','12','34','FF','FF','FF','FF','FF'].

The incoming data in the APDU buffer starts with ['24','12','34','FF','FF','FF','FF','FF'].

ParameterspresentedPin The APDU buffer or a standard array of persistent duration.offset ISO7816.OFFSET_CDATAlength 4

ProcedurereferencePin.check(presentedPin,offset,length)TEST CASE 2

Preconditions

The PIN is coded in hexadecimal format: referencePin has been updated with ['01','02','03','04'].

The incoming data in the APDU buffer starts with ['01','02','03','04'].

ParameterspresentedPin The APDU buffer or a standard array of persistent duration.offset ISO7816.OFFSET_CDATAlength 8

ProcedurereferencePin.check(presentedPin,offset,length)TEST getTriesRemainingTEST CASE 1

Preconditions

referencePin has been updated.

ProcedurereferencePin.getTriesRemaining()TEST isValidatedTEST CASE 1

Preconditions

referencePin has been updated.

ProcedurereferencePin.isValidated()

©Mesure Project, 2006-2007 page 15/68

Page 16: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.OwnerPINTEST CASE 2

Preconditions

referencePin has been validated.

ProcedurereferencePin.isValidated()TEST resetTEST CASE 1

Preconditions

referencePin has been updated.

ProcedurereferencePin.reset()TEST CASE 2

Preconditions

referencePin has been validated.

ProcedurereferencePin.reset()TEST resetAndUnblockSome applications only rely on the OwnerPIN class to store securely the PIN, but manage themselves the PIN Verification Status and the PIN Try Counter. The resetAndUnblock method is then useful during the normal use phase of these applications.

TEST CASE 1

Preconditions

referencePin has been updated.

ProcedurereferencePin.resetAndUnblock()TEST CASE 2

Preconditions

referencePin has been validated.

ProcedurereferencePin.resetAndUnblock()

©Mesure Project, 2006-2007 page 16/68

Page 17: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.security.DESKeyTEST getKeyThis method is often used by applications when derivating session keys from master keys.

TEST CASE 1

Parameterskey A persistent 128-bit DES keykeyData A byte array of CLEAR ON DESELECT durationkOff 0

Preconditions

key has been initialized.

Procedurekey.getKey(keyData,kOff)TEST setKeyThis method is often used by applications when derivating session keys from master keys.

TEST CASE 1

Parameterskey A transient 64-bit DES key of CLEAR ON DESELECT durationkeyData A byte array of CLEAR ON DESELECT durationkOff 0

Procedurekey.setKey(keyData,kOff)

javacard.security.RSAPublicKeyjavacard.security.RSAPrivateKey

TEST setExponentTEST CASE 1

Parameterskey An RSA public (resp. private) key. All specified lengths specified in

KeyBuilder class for RSA keys (LENGTH_RSA_XXX) are considered.bArray A byte array of persistent or of CLEAR ON DESELECT duration.bOff 0bLen LENGTH_RSA_XXX / 8Procedurekey.setExponent(bArray,bOff,bLen)

©Mesure Project, 2006-2007 page 17/68

Page 18: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.security.RSAPublicKeyjavacard.security.RSAPrivateKey

TEST setModulusTEST CASE 1

Parameterskey An RSA public (resp. private) key. All specified lengths specified in

KeyBuilder class for RSA keys (LENGTH_RSA_XXX) are considered.bArray A byte array of persistent or of CLEAR ON DESELECT duration.bOff 0bLen LENGTH_RSA_XXX / 8Procedurekey.setModulus(bArray,bOff,bLen)

javacard.security.RSAPrivateCrtKeyTEST setPIn the same manner, the setQ, setDP1, setDQ1 and setPQ methods are considered and similar tests are defined.

TEST CASE 1

Parameterskey An RSA CRT private key. All specified lengths specified in

KeyBuilder class for RSA keys (LENGTH_RSA_XXX) are considered.bArray A byte array of persistent or of CLEAR ON DESELECT duration.bOff 0bLen LENGTH_RSA_XXX / 16Procedurekey.setP(bArray,bOff,bLen)

javacard.security.KeyParameterskey A key. All specified types and lengths specified in KeyBuilder class

are considered.

Preconditions

key has been initialized.

TEST clearKeyTEST CASE 1

Procedurekey.clearKey()

©Mesure Project, 2006-2007 page 18/68

Page 19: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.security.KeyTEST getTypeTEST CASE 1

Procedurekey.getType()TEST getSizeTEST CASE 1

Procedurekey.getSize()

javacard.crypto.Ciphercipher A Cipher object.

Unless explicitly mentioned in the test description, the following algorithms are considered:

• Cipher.ALG_DES_CBC_ISO9797_M1• Cipher.ALG_DES_CBC_ISO9797_M2• Cipher.ALG_DES_CBC_NOPAD• Cipher.ALG_DES_ECB_ISO9797_M1• Cipher.AMG_DES_ECB_ISO9797_M2• Cipher.ALG_DES_ECB_NOPAD• Cipher.ALG_RSA_NOPAD• Cipher.ALG_RSA_PKCS1

For DES-based algorithms, the TYPE_DES and TYPE_DES_TRANSIENT_DESELECT types are considered, with all specified lengths (LENGTH_DES, LENGTH_DES3_2KEY, LENGTH_DES3_3KEY).

For RSA-based algorithms, all types (TYPE_RSA_CRT_PRIVATE, TYPE_RSA_PRIVATE and TYPE_RSA_PUBLIC) are tested, as well as all specified lengths (LENGTH_RSA_1024, LENGTH_RSA_2048, LENGTH_RSA_512, LENGTH_RSA_768).

TEST init(Key,byte)TEST CASE 1

Parameters

theKey A Key objecttheMode Both modes (MODE_ENCRYPT, MODE_DECRYPT) are considered.

Preconditions

theKey is initialized.

Procedurecipher.init(theKey,theMode)

©Mesure Project, 2006-2007 page 19/68

Page 20: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.crypto.CipherTEST doFinalTEST CASE 1

Preconditions

cipher has been initialized using cipher.init(Key,byte).

ParametersinBuff The following input buffers are considered: the APDU buffer, and a

byte array of CLEAR ON DESELECT duration (for security reasons, data to be enciphered/deciphered are generally stored in transient memory).

inOffset The following offsets are considered: 0, 64, 128, 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

inLength The following lengths are considered for DES-based algorithms: 8 (block size), 16 and 24.

The following lengths are considered for RSA-based algorithm without padding: modulus length (i.e. key length / 8 bits).

The following lengths are considered for RSA-based algorithm with PKCS1 padding: modulus length – 11.

If the APDU buffer is tested, the lengths that are out of bounds are excluded.

outBuff The following output buffers are considered: the APDU buffer and a byte array of CLEAR ON DESELECT duration.

outOffset If inOffset=0, the following offsets are considered: 64, 128, 172; otherwise, the offset 0 is considered. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

Procedurecipher.doFinal(inBuff,inOffset,inLength,outBuff,outOffset)TEST CASE 2

Preconditions

cipher has been initialized using cipher.init(Key,byte).

ParametersinBuff The following input buffers are considered: the APDU buffer and a

byte array of CLEAR ON DESELECT duration. inOffset The following offsets are considered: 0, 64, 128, 172. If the APDU

buffer is tested, the offsets that are out of bounds are excluded.inLength The following lengths are considered for DES-based algorithms: 8

(block size), 16 and 24.

The following lengths are considered for RSA-based algorithm without padding: modulus length (i.e. key length / 8 bits).

The following lengths are considered for RSA-based algorithm with PKCS1 padding: modulus length – 11.

©Mesure Project, 2006-2007 page 20/68

Page 21: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.crypto.CipherIf the APDU buffer is tested, the lengths that are out of bounds are excluded.

outBuff inBuff outOffset inOffsetProcedurecipher.doFinal(inBuff,inOffset,inLength,outBuff,outOffset)

javacard.security.MessageDigestdigest A MessageDigest object with type ALG_SHA.

TEST doFinalTEST CASE 1

ParametersinBuff The following input buffers are considered: the APDU buffer and a

byte array of CLEAR ON DESELECT duration. inOffset The following offsets are considered: 0, 64, 128, 172. If the APDU

buffer is tested, the offsets that are out of bounds are excluded.inLength The following lengths are considered: 64 (block size), 128 and 192.

If the APDU buffer is tested, the lengths that are out of bounds are excluded.

outBuff The following output buffers are considered: the APDU buffer and a byte array of CLEAR ON DESELECT duration.

outOffset If inOffset=0, the following offsets are considered: 64, 128, 172; otherwise, the offset 0 is considered. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

Proceduredigest.doFinal(inBuff,inOffset,inLength,outBuff,outOffset)TEST CASE 2

ParametersinBuff The following input buffers are considered: the APDU buffer and a

byte array of CLEAR ON DESELECT duration. inOffset The following offsets are considered: 0, 64, 128, 172. If the APDU

buffer is tested, the offsets that are out of bounds are excluded.inLength The following lengths are considered: 64 (block size), 128 and 192.

If the APDU buffer is tested, the lengths that are out of bounds are excluded.

outBuff inBuffoutOffset inOffsetProceduredigest.doFinal(inBuff,inOffset,inLength,outBuff,outOffset)

©Mesure Project, 2006-2007 page 21/68

Page 22: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.security.Signaturesignature A Signature object.

Unless explicitly mentioned in the test description, the following algorithms are considered:

• Signature.ALG_DES_MAC8_ISO9797_M1• Signature.ALG_DES_MAC8_ISO9797_M2• Signature.ALG_DES_MAC8_NOPAD• Signature.ALG_RSA_SHA_ISO9796• Signature.ALG_RSA_SHA_PKCS1

For DES-based algorithms, the TYPE_DES and TYPE_DES_TRANSIENT_DESELECT types are considered, with all specified lengths (LENGTH_DES, LENGTH_DES3_2KEY, LENGTH_DES3_3KEY).

For RSA-based algorithms, all types (TYPE_RSA_CRT_PRIVATE, TYPE_RSA_PRIVATE and TYPE_RSA_PUBLIC) are tested, as well as all specified lengths (LENGTH_RSA_1024, LENGTH_RSA_2048, LENGTH_RSA_512, LENGTH_RSA_768).

TEST init(Key,byte,byte[],short,short)TEST CASE 1

Parameters

theKey A DESKey object.theMode Both modes (MODE_SIGN, MODE_VERIFY) are considered. bArray The following input buffers are considered: a byte array of

persistent duration and a byte array of CLEAR ON DESELECT duration.

This array is filled with 0.bOff 0bLen 8

Preconditions

signature is a DES-based algorithm (in CBC mode) and theKey is initialized.

Proceduresignature.init(theKey,theMode,bArray,bOff,bLen)TEST init(Key,byte)TEST CASE 1

Parameters

theKey A Key object.theMode Both modes (MODE_SIGN, MODE_VERIFY) are considered.

Proceduresignature.init(theKey,theMode)

©Mesure Project, 2006-2007 page 22/68

Page 23: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.security.SignatureTEST signTEST CASE 1

Preconditions

signature has been initialized using Signature.init(Key,byte) in MODE_SIGN mode.

ParametersinBuff The following input buffers are considered: the APDU buffer and a

byte array of CLEAR ON DESELECT duration (for security reasons, cryptographic computations are generally performed on transient memory).

inOffset 0inLength The following lengths are considered for DES-based algorithms: 8

(block size), 40, 80.

The following lengths are considered for RSA-based algorithms: 64, 128 and 192.

If the APDU buffer is tested, the lengths that are out of bounds are excluded.

outBuff The following output buffers are considered: the APDU buffer and a byte array of CLEAR ON DESELECT duration.

outOffset The following offsets are considered: 64, 128, 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

Proceduresignature.sign(inBuff,inOffset,inLength,sigBuff,sigOffset)TEST verifyTEST CASE 1

Preconditions

signature has been initialized using Signature.init(Key,byte) in MODE_VERIFY mode.

ParametersinBuff A byte array of persistent duration (Signature objects are

frequently used in MODE_VERIFY mode to check integrity of persistent sensitive data).

inOffset 0inLength The following lengths are considered for DES-based algorithms: 8

(block size), 40, 80.

The following lengths are considered for RSA-based algorithms: 64, 128 and 192.

sigBuff A persistent byte array.

inBuff and sigBuff are distinct.sigOffset 0sigLength For DES-based algorithms: 8.

For RSA-based algorithm: modulus length.

©Mesure Project, 2006-2007 page 23/68

Page 24: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.security.SignatureProceduresignature.verify(inBuff,inOffset,inLength,sigBuff,sigOffset,sigLength)

javacard.security.RandomDatarandom A RandomData object with type ALG_SECURE_RANDOM.

TEST generateDataTEST CASE 1

Parametersbuffer The following input buffers are considered: the APDU buffer and

a byte array of CLEAR ON DESELECT duration (for security reasons, cryptographic computations are generally performed on transient memory).

offset The following offsets are considered: 0, 64, 128, 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

length 8

ProcedureRandom.generateData(buffer,offset,length)

3.1.2 UtilitiesThe Util class includes a set of very simple methods that perform memory operations, which are often written in native code rather than in Java, for performance reasons. As a consequence, it is necessary to include them in the test bench.

javacard.framework.Util

TEST arrayCompareTEST CASE 1

Parameterssrc The following buffers are considered: the APDU buffer, a byte array

of CLEAR ON DESELECT duration, a byte array of persistent duration.

srcOff The following offsets are considered: 0, 64, 128 and 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

dest The following buffers are considered: the APDU buffer, a byte array of CLEAR ON DESELECT duration, a byte array of persistent duration.

src and dest are filled with the same values.destOff If srcOff=0, the following offsets are considered: 64, 128, 172;

otherwise, the offset 0 is considered. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

©Mesure Project, 2006-2007 page 24/68

Page 25: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.Utillength The following lengths are considered: 1, 2, 4, 8, 16, 32, 64, 128,

256.

If the APDU buffer is tested, the lengths that are out of bounds are excluded.

ProcedureUtil.arrayCompare(src,srcOff,dest,destOff,length)TEST arrayCopyTEST CASE 1

Preconditions

A transaction has been started.

Parameterssrc The following source buffers are considered: the APDU buffer and a

byte array of CLEAR ON DESELECT duration.srcOff The following offsets are considered: 0, 64, 128 and 172. If the

APDU buffer is tested, the offsets that are out of bounds are excluded.

dest The following destination buffers are considered: a byte array of persistent duration.

destOff If srcOff=0, the following offsets are considered: 64, 128, 172; otherwise, the offset 0 is considered. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

length The following lengths are considered: 1, 2, 4, 8, 16, 32, 64, 128, 256. If the APDU buffer is tested, the lengths that are out of bounds are excluded.

ProcedureJCSystem.beginTransaction()Util.arrayCopy(src,srcOff,dest,destOff,length)JCSystem.commitTransaction()TEST CASE 2

Preconditions

No transaction has been started.

Parameterssrc The following source buffers are considered: the APDU buffer, a

byte array of CLEAR ON DESELECT duration and a byte array of persistent duration.

srcOff The following offsets are considered: 0, 64, 128 and 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

dest The following destination buffers are considered: the APDU buffer and a byte array of CLEAR ON DESELECT duration.

destOff If srcOff=0, the following offsets are considered: 64, 128, 172;

©Mesure Project, 2006-2007 page 25/68

Page 26: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.Utilotherwise, the offset 0 is considered. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

length The following lengths are considered: 1, 2, 4, 8, 16, 32, 64, 128, 256. If the APDU buffer is tested, the lengths that are out of bounds are excluded.

ProcedureUtil.arrayCopy(src,srcOff,dest,destOff,length)TEST arrayCopyNonAtomicTEST CASE 1

Preconditions

No transaction has been started.

Parameterssrc The following source buffers are considered: the APDU buffer, a

byte array of CLEAR ON DESELECT duration and a byte array of persistent duration.

srcOff The following offsets are considered: 0, 64, 128 and 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

dest The following destination buffers are considered: the APDU buffer, a byte array of CLEAR ON DESELECT duration and a byte array of persistent duration.

destOff If srcOff=0, the following offsets are considered: 64, 128, 172; otherwise, the offset 0 is considered. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

length The following lengths are considered: 1, 2, 4, 8, 16, 32, 64, 128, 256. If the APDU buffer is tested, the lengths that are out of bounds are excluded.

ProcedureUtil.arrayCopyNonAtomic(src,srcOff,dest,destOff,length)TEST arrayFillNonAtomicTEST CASE 1

Preconditions

No transaction has been started.

Parametersbarray The following source buffers are considered: the APDU buffer, a

byte array of CLEAR ON DESELECT duration and a byte array of persistent duration.

bOff The following offsets are considered: 0, 64, 128, 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

bLen The following lengths are considered: 1, 2, 4, 8, 16, 32, 64, 128, 256. If the APDU buffer is tested, the lengths that are out of bounds are excluded.

©Mesure Project, 2006-2007 page 26/68

Page 27: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.UtilbValue 0

ProcedureUtil.arrayFillNonAtomic(bArray,bOff,bLen,bValue)TEST getShortTEST CASE 1

Preconditions

A transaction has been started.

Parametersbarray The following source buffers are considered: a byte array of

persistent duration.bOff The following offsets are considered: 0, 64, 128, 172. If the

APDU buffer is tested, the offsets that are out of bounds are excluded.

ProcedureUtil.getShort(bArray,bOff)TEST CASE 1

Preconditions

No transaction has been started.

Parametersbarray The following source buffers are considered: the APDU buffer, a

byte array of CLEAR ON DESELECT duration, a byte array of persistent duration.

bOff The following offsets are considered: 0, 64, 128, 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

ProcedureUtil.getShort(bArray,bOff)TEST makeShortTEST CASE 1

Parametersb1 0b2 'FF'

ProcedureUtil.makeShort(b1,b2)

©Mesure Project, 2006-2007 page 27/68

Page 28: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.UtilTEST setShortTEST CASE 1

Preconditions

A transaction has been started.

ParametersbArray A byte array of persistent duration.bOff The following offsets are considered: 0, 64, 128, 172. sValue '57E4'

ProcedureJCSystem.beginTransaction()Util.setShort(bArray,bOff,sValue)JCSystem.commitTransaction()TEST CASE 2

Preconditions

No transaction has been started.

ParametersbArray The following buffers are considered: the APDU buffer, a byte

array of persistent duration, a byte array of CLEAR ON DESELECT duration.

bOff The following offsets are considered: 0, 64, 128, 172. If the APDU buffer is tested, the offsets that are out of bounds are excluded.

sValue '57E4'

ProcedureUtil.setShort(bArray,bOff,sValue)

javacard.framework.JCSystemTEST beginTransaction / commitTransactionThis test has to be correlated with the previous tests performed during a transaction.

TEST CASE 1

Preconditions

No transaction has been started.

ProcedureJCSystem.beginTransaction()JCSystem.commitTransaction()TEST getAIDTEST CASE 1

ProcedureJCSystem.getAID()

©Mesure Project, 2006-2007 page 28/68

Page 29: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.AIDTEST getBytesTEST CASE 1

Parametersaid The Java Card RE owned-AID instance encapsulating the AID of

the currently selected applet (eg. 11 bytes).

This method is sometimes invoked on the AID returned by the JCSystem.getAID method to build the FCI returned on applet selection.

bArray The APDU buffer.bOff 4

Procedureaid.getBytes(bArray,bOff)TEST partialEqualsTEST CASE 1

Parametersaid The Java Card RE owned-AID instance encapsulating the AID of

the currently selected applet (eg. 11 bytes).

This method is sometimes invoked on the AID returned by the JCSystem.getAID method on applet selection (instead of Applet.selectingApplet).

bArray The APDU buffer.bOff 5bLen 8

Procedureaid.partialEquals(bArray,bOff,bLen)

javacard.framework.APDUTEST getBufferTEST CASE 1

ProcedureAPDU.getBuffer()TEST getProtocolTEST CASE 1

ProcedureAPDU.getProtocol()

©Mesure Project, 2006-2007 page 29/68

Page 30: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard.framework.AppletTEST selectingAppletTEST CASE 1

Preconditions

The APDU command currently processed is a SELECT command and the AID contained in its data field is a registered AID.

ProcedureApplet.selectingApplet()TEST CASE 2

Preconditions

The APDU command currently processed is not a SELECT command.

ProcedureApplet.selectingApplet()TEST selectSome applets invoke super.select() from their own select method.

TEST CASE 1

ProcedureApplet.select()

3.2 Java Card VM

Here after we list the different bytecodes evaluated. For each bytecode, we consider the potential impact of the environment.

AALOADTEST [STD]TEST CASE 1

This test is implemented in bytecode (in JCA format).

To perform aaload, we need to have a short value and an Object array reference on top of the stack.

One way to achieve this may be by performing a getfield_a_this followed by a getfield_a on an Object array reference. Then, we can perform a sconst_0 to push the short value onto the stack.

ACONST_NULLTEST

This test is implemented in javacard.

TEST CASE aconst_null

Measure 1 call to aconst_null.

TEST CASE aconst_null * 2

Measure 2 calls to aconst_null (in order to increase measure precision).

©Mesure Project, 2006-2007 page 30/68

Page 31: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

ACONST_NULLTEST CASE aconst_null * 3

Measure 3 calls to aconst_null.

ALOADTEST

This test is coded in bytecode.

To perform the aload bytecode, we need at least four local objects. These objects can be created thanks to a series of aconst_null/astore bytecodes. Then, we can perform the aload bytecode on the fourth element (aload 4). The reference test just needs to perform the same bytecodes except for the aload bytecode.

ALOAD_0TEST

This test is coded in javacard.

aload_0 is generated using the unit_v1a(l0) call, l0 being an object on stack of a static method. Other aload bytecodes are generated in a similar way, when second, third, fourth variable are passed as an argument to the dummy method.

TEST CASE aload_0

Measure 1 call to aload_0.

TEST CASE aload_0 * 2

Measure 2 calls to aload_0 (in order to increase precision).

TEST CASE aload_0 * 3

Measure 3 calls to aload_0.

ALOAD_1TEST

Similar to aload_0. aload_1 is generated using the the unit_v1a(l1) call, l1 being the second variable on stack (of type reference) of a static method.

ALOAD_2TEST

Similar to aload_0. aload_2 is generated using the the unit_v1a(l2) call, l2 being the third variable on stack (of type reference) of a static method.

ALOAD_3TEST

Similar to aload_0. aload_3 is generated using the the unit_v1a(l3) call, l3 being the fourth variable on stack (of type reference) of a static method.

©Mesure Project, 2006-2007 page 31/68

Page 32: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

ARRAYLENGTHTEST [COD]

This test is coded in bytecode.

To perform this bytecode we need a CLEAR ON DESELECT array (which is obtained using the JCSystem.makeTransientByteArray method). In the tested method, we basically need to perform a getfield_a_this, then we need to do a getfield_a on the array.

TEST [STD]

This test was coded in bytecode.

This test is similar to the previous test: a standard array is used instead.

ASTORETEST

This test is coded in bytecode.

To perform an astore bytecode we need to have at least four local objects. It can be achieved thanks to a getstatic_a bytecode. We basically just push a static object onto the stack and just store it as the fourth local object with the astore bytecode. There is no need to push the four objects onto the stack.

ASTORE_0TEST

This test is coded in bytecode.

To perform the astore_0 we need to have an object on top of the stack. We can use a static object with the getstatic_a bytecode.

ASTORE_1TEST

Very similar to astore_0. We just need an additional local variable.

ASTORE_2TEST

Very similar to astore_0. We just need two additional local variables.

ASTORE_3TEST

Very similar to astore_0. We just need three additional local variables.

BALOADTEST

TEST CASE first

Reads first byte of an array allocated on heap.

TEST CASE rand

©Mesure Project, 2006-2007 page 32/68

Page 33: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

BALOADReads bytes of an array allocated on heap in a random order (this order is calculated off line).

TEST CASE seq

Reads bytes of an array allocated on heap in a sequential order.

TEST CASE transaction_abort

Reads bytes of an array allocated on heap in a sequential order, in an aborted transaction.

TEST CASE transaction_commit

Reads bytes of an array allocated on heap in a sequential order, in a committed transaction.

BASTORETEST

TEST CASE first

Writes first byte of an array allocated on heap.

TEST CASE transaction_abort

Writes bytes of an array allocated on heap in a sequential order, in an aborted transaction.

TEST CASE transaction_commit

Writes bytes of an array allocated on heap in a sequential order, in a committed transaction.

TEST CASE rand

Writes bytes of an array allocated on heap in a random order (this order is calculated off line).

TEST CASE rand transaction_abort

Writes bytes of an array allocated on heap in a random order (this order is calculated off line), in an aborted transaction.

TEST CASE rand transaction_commit

Writes bytes of an array allocated on heap in a random order (this order is calculated off line), in a committed transaction.

TEST CASE seq

Writes bytes of an array allocated on heap in a sequential order.

TEST CASE seq transaction_abort

Writes bytes of an array allocated on heap in a sequential order, in an aborted transaction.

TEST CASE seq transaction_commit

Writes bytes of an array allocated on heap in a sequential order, in a committed transaction.

©Mesure Project, 2006-2007 page 33/68

Page 34: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

BSPUSHTEST

TEST CASE bspush

Executes 1 bspush. Generated using the following call: unit_v1s((short)6).

(See StackTestApplet.java)

TEST CASE bspush * 2

Executes 2 bspush.

TEST CASE bspush * 3

Executes 3 bspush.

TEST CASE bspush 127

Evaluates bspush on a commonly used special value.

TEST CASE -128

Evaluates bspush on a commonly used special value.

CHECKCASTTEST

TEST CASE C1

Casts object to grand-parent class.

(See TypesTestApplet.java)

TEST CASE C2

Casts object to parent class.

TEST CASE I1

Casts object to grand-parent interface.

TEST CASE I2

Casts object to parent interface.

TEST CASE I31

Casts object to first implemented interface.

TEST CASE I32

Casts object to second implemented interface.

TEST CASE I33

Casts object to third implemented interface.

DUPTEST

This test is coded in javacard. It depends on sstore_0.

©Mesure Project, 2006-2007 page 34/68

Page 35: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

DUP2TEST

We need to stack at least two short values to test dup2. We use sconst_0 to do that. This test is coded in bytecode. We actually stack four short values thanks to the sconst_0 bytecode to compare its measurement with the measurement obtained for the dup_x bytecode.

DUP_XTEST

The dup_x bytecode reads an argument prior to the duplication of some elements in the stack. With a 16-bits architecture, the argument can be either one of 0x10, 0x11, 0x12, 0x13, 0x20, 0x22, 0x23, 0x24 (the values are given in hexadecimal format).

The argument 0x24 implies that we need to have at least 4 short values stacked up before using the bytecode. We can use sconst_0 to build the stack.

This test is coded in bytecode.

TEST CASE 0x10

0x10 is chosen as argument

TEST CASE 0x11

0x11 is chosen as argument

TEST CASE 0x12

0x12 is chosen as argument

TEST CASE 0x13

0x13 is chosen as argument

TEST CASE 0x20

0x20 is chosen as argument

TEST CASE 0x22

0x22 is chosen as argument

TEST CASE 0x23

0x23 is chosen as argument

TEST CASE 0x24

0x24 is chosen as argument

GETFIELD_ATEST

Accesses an object field. Depends on: aload_3, sstore.

(See FieldTestApplet.java)

GETFIELD_A_THISTEST

Similar to getfield_a, but applied to this. Depends on: aload_4, sstore.

©Mesure Project, 2006-2007 page 35/68

Page 36: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

GETFIELD_BTEST

Gets a byte field from an object. Depends on: aload_4, sstore_3.

GETFIELD_B_THISTEST

Gets a byte field from this object. Depends on: sstore_3.

GETFIELD_STEST

Gets a short field from an object. Depends on: aload_4, sstore_3.

GETFIELD_S_THISTEST

Gets a short field from this object. Depends on: sstore_3.

GETSTATIC_ATEST

This test is coded in bytecode. We need to work with a dummy object which is pushed onto the stack. The reference test does nothing.

GETSTATIC_BTEST

This test is coded in javacard.

Depends on: sstore_2.

GETSTATIC_STEST

This test is coded in javacard.

Depends on: sstore_2.

GOTOTEST

This test is coded in bytecode.

We just need to have an address to perform the test. The reference test does nothing.

GOTO_WTEST

This is quite similar to the test for GOTO.

To use a wide address, we need to perform some bytecode like SINC to artificially increase the addresses range.

©Mesure Project, 2006-2007 page 36/68

Page 37: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

IFEQTEST

TEST CASE IFEQ_OK

Tests the successful ifeq. Depends on: sload_2.

TEST CASE IFEQ_KO

Tests a failure in the ifeq condition. Depends on: sload_2.

IFEQ_WTEST

TEST CASE IFEQ_W_OK

Tests the successful ifeq_w. Depends on: sload_2.

TEST CASE IFEQ_W_KO

Tests a failure in the ifeq_w condition. Depends on: sload_2.

IFGETEST

This test is coded in bytecode.

We need to have a recorded address as argument.

Since the basic implementation will perform a goto in case of test failure, the reference case needs to perform an additional goto only when the test fails. It means that we basically need two reference tests : one with the additional goto that will be used as a reference for the failed test and one without the goto which will be used as a reference for the successful test.

Those references will work for many if<test> bytecodes on a non wide address. The test requires a stack with at least a short value on top. We use the sconst_n bytecodes to perform the test with n=1 for the successful test and n=m1 for the failure test.

TEST CASE IFGE_OK

Tests the successful ifge.

TEST CASE IFGE_KO

Tests a failure in the ifge condition.

IFGTTEST

TEST CASE IFGT_OK

Depends on: sload_2.

TEST CASE IFGT_KO

Depends on: sload_2.

©Mesure Project, 2006-2007 page 37/68

Page 38: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

IFLETEST

Similar to ifge.

IFLTTEST

Similar to ifge.

IFNETEST

TEST CASE IFNE_OK

Depends on: sload_2.

TEST CASE IFNE_KO

Depends on: sload_2.

IFNONNULLTEST

TEST CASE IFNONNULL_OK

Depends on: aload_2.

TEST CASE IFNONNULL_KO

Depends on: aload_2.

IFNULLTEST

This test is coded in bytecode.

We need to have a recorded address as an argument.

Since the basic implementation will perform a goto in case of test failure, the reference case needs to perform an additional goto only when the test fails. It means that we basically need two reference tests: one with the additional goto that will be used as a reference for the failed test and one without the goto which will be used as a reference for the successful test.

The test requires a stack with at least one object value on top. We need a (static) dummy object, which is pushed onto the stack with a getstatic_a bytecode for the failed test, and we push a null value onto the stack thanks to an aconst_null bytecode for the successful test. The reference test cases act accordingly.

TEST CASE IFNULL_OK

Tests the successful ifnull.

TEST CASE IFNULL_KO

Tests a failure in the ifnull condition.

©Mesure Project, 2006-2007 page 38/68

Page 39: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

IF_SCMPEQTEST

This test is coded in bytecode.

We need to have a recorded address as an argument.

Since the basic implementation will perform a goto in case of test failure, the reference case needs to perform an additional goto only when the test fails. This means we basically need two reference tests: one with the additional goto that will be used as a reference for the failed test and one without the goto which will be used as a reference for the successful test.

Those references will work for many if_scmp<test> bytecodes on a non wide address. The test requires a stack with at least two short values on top. We use the sconst_n/ sconst_m bytecodes to perform the test with m=n=1 for the successful test and n=0 m=1 for the failure test.

TEST CASE IFSCMPEQ_OK

Tests the successful ifscmpeq.

TEST CASE IFSCMPEQ_KO

Tests a failure in the ifscmpeq condition.

IF_SCMPGETEST

Similar to ifscmpeq.

IF_SCMPGTTEST

Similar to ifscmpeq.

IF_SMCPGT_WTEST

This test is coded in javacard.

TEST CASE IFSCMPGT_W_OK

Depends on: SLOAD_2, SLOAD_2.

TEST CASE IFSCMPGT_W_KO

Depends on: SLOAD_2, SLOAD_2, goto_w.

IF_SCMPLETEST

Similar to ifscmpeq.

IF_SCMPLTTEST

Similar to ifscmpeq.

©Mesure Project, 2006-2007 page 39/68

Page 40: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

IF_SCMPNETEST

Similar to ifscmpeq.

INVOKESTATIC+RETURNTEST

We can't easily isolate invokestatic of return.

So we evaluate invokestatic in several ways in order to increase the precision of results:

• INVOKESTATIC+RETURN

• INVOKESTATIC+RETURN+noCATCH (performs invocation inside a try/catch)

• INVOKESTATIC+THROW+CATCH (performs invocation raising an exception inside a try/catch)

• INVOKESTATIC+THROW+CATCH+RETURN (same but explicitly calls return)

(See InvokeTestApplet.java)

INVOKESPECIAL+RETURNTEST

Evaluates the invokespecial (+ return) bytecode.

It is generated by calling a private method. This bytecode can be generated in other ways, for example by using a super clause.

INVOKEVIRTUAL+RETURNTEST

Evaluates the invokevirtual (+ return) bytecode.

It is generated by calling a public method. This bytecode can be generated in several ways:

• When invoking a method of the class

• When invoking a looked up super method of the class: method {super}+ class

• When invoking a looked up super method of other packages: method {cap.{super}^+}^+ class

POPTEST

This test is coded in javacard.

Depends on: sload_0.

PUTFIELD_ATEST

Depends on: aload_4, aconst_null.

©Mesure Project, 2006-2007 page 40/68

Page 41: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

PUTFIELD_BTEST

Depends on: aload_4, sconst_0.

PUTFIELD_STEST

Depends on: aload_4, sconst_0.

PUTSTATIC_ATEST

Depends on: aconst_null.

S2BTEST

Evaluates the short to byte conversion.

SADDTEST

This test is coded in bytecode.

We need to have two short values on top of the stack before performing this bytecode. This can be achieved thanks to two sconst_3 bytecodes.

SALOADTEST

TEST CASE first

Evaluates the loading time of a short value at first index of a static array.

TEST CASE rand

Evaluates the loading time of a short value at random index of a static array.

TEST CASE seq

Evaluates the loading time of a short value read sequentially from a static array.

TEST CASE transaction_abort

Evaluates the loading time of a short value read sequentially from a static array, in an aborted transaction.

TEST CASE transaction_commit

Evaluates the loading time of a short value read sequentially from a static array, in a committed transaction.

SANDTEST

This test is similar to the “bytecode” version of the sadd test.

©Mesure Project, 2006-2007 page 41/68

Page 42: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

SASTORETEST

TEST CASE first

Evaluates the storage time of a short value at first index of a static array.

TEST CASE transaction_abort

Evaluates the storage time of a short value at first index of a static array, in an aborted transaction.

TEST CASE transaction_commit

Evaluates the storage time of a short value at first index of a static array, in a committed transaction.

TEST CASE rand

Evaluates the storage time of a short value at random index of a static array.

TEST CASE rand_transaction_abort

Evaluates the storage time of a short value at random index of a static array, in an aborted transaction.

TEST CASE rand_transaction_commit

Evaluates the storage time of a short value at random index of a static array, in a committed transaction.

TEST CASE seq

Evaluates the storage time of a short value written sequentially to a static array.

TEST CASE seq_transaction_abort

Evaluates the storage time of a short value written sequentially to a static array, in an aborted transaction.

TEST CASE seq_transaction_commit

Evaluates the storage time of a short value written sequentially to a static array, in a committed transaction.

SCONST_0TEST

This test is coded in javacard.

TEST CASE sconst_0

Evaluates the sconst_0 bytecode.

TEST CASE sconst_0 * 2

Evaluates two sconst_0 bytecodes (in order to increase the precision).

TEST CASE sconst_0 * 3

Evaluates three sconst_0 bytecodes (in order to increase the precision).

©Mesure Project, 2006-2007 page 42/68

Page 43: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

SCONST_1TEST

Similar to sconst_0.

SCONST_2TEST

Similar to sconst_0.

SCONST_3TEST

Similar to sconst_0.

SCONST_4TEST

Similar to sconst_0.

It is expected to be slower than sconst_0 since argument is probably fetched.

SCONST_5TEST

Similar to sconst_0.

It is expected to be slower than sconst_0 since argument is probably fetched.

SDIVTEST

TEST CASE 1

This test is quite similar to the "bytecode" test of sadd.

We can replace the first sconst_3 with a sspush 32767 (32767 being the biggest positive short value). It will lead to the division of a (relatively) big number.

TEST CASE 2

This test is quite similar to the "bytecode" test of sadd.

We can replace the first sconst_3 with a sconst_0. It will lead to the division of 0.

SINCTEST

Evaluates the sinc bytecode.

SLOADTEST

sload_4 and sload_5 should be equivalent to sload.

©Mesure Project, 2006-2007 page 43/68

Page 44: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

SLOAD_0TEST

TEST CASE sload_0

Evaluates the sload_0 bytecode.

TEST CASE sload_0 * 2

Evaluates two sload_0 bytecodes (in order to increase the precision).

TEST CASE sload_0 * 3

Evaluates three sload_0 bytecodes (in order to increase the precision).

SLOAD_1TEST

Similar to sload_0.

SLOAD_2TEST

Similar to sload_0.

SLOAD_3TEST

Similar to sload_0.

SLOAD_4TEST

Similar to sload_0. It is however expected to be slower than sload_0.

SLOAD_5TEST

Similar to sload_0. It is expected to be equivalent to sload_4.

SLOOKUPSWITCHTEST

TEST CASE 1

Case 1 is executed.

TEST CASE 2

Case 2 is executed.

TEST CASE 3

Case 5 is executed.

TEST CASE 4

Case 100 is executed.

©Mesure Project, 2006-2007 page 44/68

Page 45: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

SLOOKUPSWITCHTEST CASE 5

Case 0 is executed. It falls back to default, as it doesn't exist.

TEST CASE 6

Case 60 is executed. It falls back to default, as it doesn't exist.

TEST CASE 7

Case 200 is executed. It falls back to default, as it doesn't exist.

SMULTEST

This test is quite similar to the "bytecode" test of sadd.

SNEGTEST

This test is coded in bytecode.

To test sneg, we need to have a short value on top of the stack. One way to do this may be to push a short thanks to a sconst_0 bytecode onto the stack.

SORTEST

This test is quite similar to the "bytecode" test of sadd.

SREMTEST

This test is quite similar to the "bytecode" test of sdiv.

SSHLTEST

This test is quite similar to the "bytecode" test of sadd.

SSHRTEST

This test is quite similar to the "bytecode" test of sadd.

SSPUSHTEST

TEST CASE sspush

Evaluates the sspush bytecode.

TEST CASE sspush * 2

Evaluates two sspush bytecodes (in order to increase the precision).

©Mesure Project, 2006-2007 page 45/68

Page 46: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

SSPUSHTEST CASE sspush * 3

Evaluates three sspush bytecodes (in order to increase the precision).

SSTORETEST

TEST CASE 1

Stores to 5th local variable of method.

TEST CASE 2

Stores to 6th local variable of method.

SSTORE_0TEST

Stores to first local variable of method.

SSTORE_1TEST

Stores to second local variable of method.

SSTORE_2TEST

Stores to third local variable of method.

SSTORE_3TEST

Stores to fourth local variable of method.

SSUBTEST

This test is quite similar to the "bytecode" test of sadd.

STABLESWITCHTEST

TEST CASE 1

Case 0 is executed.

TEST CASE 2

Case 2 is executed.

TEST CASE 3

Case 3 is executed.

©Mesure Project, 2006-2007 page 46/68

Page 47: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

STABLESWITCHTEST CASE 4

Case 4 is executed.

TEST CASE 5

Case 0 is executed. It falls back to default, as it doesn't exist.

TEST CASE 6

Case 10 is executed. It falls back to default, as it doesn't exist.

SXORTEST

This test is quite similar to the "bytecode" test of sadd.

THROW+CATCHTEST

Evaluates the basic exception handling overhead (but it doesn't isolate the bytecode).

©Mesure Project, 2006-2007 page 47/68

Page 48: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

4 References

[SDG] http://java.sun.com/products/javacard/AppletDevelopersGuide.html

[EMV_BOOK1] EMV Integrated Circuit Card Specifications for Payment Systems – Book 1 – Application Independent ICC to Terminal Interface Requirements – May 2004 – Version 4.1.

[F1.2REQ] MESURE Project – F1.2 Requirements (Rapport sur l'expression des besoins) January 2007 – Version 1.0.

[F2.2MET] MESURE Project – F2.2 Methodology (Rapport sur la méthodologie d'application des mesures) – October 2007 – Version 1.0.

[CARDEDGE] http://web.inf.tu-dresden.de/~ko189283/MuscleCard

©Mesure Project, 2006-2007 page 48/68

Page 49: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

5 Annex 1 – Statistics for JavaPurse application (Sun)

API Method N Transactionjavacard/framework.Util:setShort 20 2javacard/framework.Util:arrayCopyNonAtomic 15 0javacard/framework.APDU:getBuffer 12 0javacard/framework.Util:getShort 10 0javacard/framework.Util:arrayFillNonAtomic 6 0javacard/framework.APDU:setOutgoingAndSend 5 0javacard/framework.APDU:setIncomingAndReceive 5 0javacard/framework.Util:arrayCopy 2 2javacard/framework.Util:arrayCompare 2 0javacard/framework.OwnerPIN:isValidated 2 0javacard/framework.JCSystem:commitTransaction 2 0javacard/framework.JCSystem:beginTransaction 2 0javacard/framework.OwnerPIN:check 1 0javacard/framework.JCSystem:getAID 1 0javacard/framework.Applet:selectingApplet 1 0javacard/framework.AID:getBytes 1 0

Total: 87 (ongoing transaction: 4)

API Method with array as parameter N TrFor each primitive type, the passed value is indicated. For each class type, the reference is indicated. For each array type, the length, the duration and the reference are respectively indicated:

• STD. A standard array of persistent duration.

• COD. An array of CLEAR ON DESELECT duration.

• COR. An array of CLEAR ON RESET duration.

• GLOB. A global array, i.e. the APDU buffer.

javacard/framework.Util:setShort (20 invocations)(byte[0x0006 STD]=0xa40a, short=0x00, short=0x57e4) 1 1(byte[0x0006 STD]=0xa40a, short=0x00, short=0x61a8) 1 1(byte[0x0106 GLOB]=0x9000, short=0x00, short=0x00) 2 0(byte[0x0106 GLOB]=0x9000, short=0x00, short=0x01) 1 0(byte[0x0106 GLOB]=0x9000, short=0x00, short=0x02) 1 0(byte[0x0106 GLOB]=0x9000, short=0x00, short=0x57e4) 1 0(byte[0x0106 GLOB]=0x9000, short=0x00, short=0x61a8) 1 0(byte[0x0106 GLOB]=0x9000, short=0x03, short=0x61a8) 1 0(byte[0x0106 GLOB]=0x9000, short=0x03, short=0x9c4) 1 0(byte[0x0106 GLOB]=0x9000, short=0x07, short=0x00) 1 0(byte[0x0106 GLOB]=0x9000, short=0x07, short=0x61a8) 1 0(byte[0x0106 GLOB]=0x9000, short=0x09, short=0x01) 1 0(byte[0x0106 GLOB]=0x9000, short=0x09, short=0x02) 1 0(byte[0x0106 GLOB]=0x9000, short=0x0e, short=0x00) 2 0(byte[0x0106 GLOB]=0x9000, short=0x0e, short=0x57e4) 1 0(byte[0x0106 GLOB]=0x9000, short=0x0e, short=0x61a8) 1 0(byte[0x0106 GLOB]=0x9000, short=0x10, short=0x9000) 2 0

©Mesure Project, 2006-2007 page 49/68

Page 50: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard/framework.Util:arrayCopyNonAtomic (15 invocations)(byte[0x0003 STD]=0xa30a, short=0x00, byte[0x0106 GLOB]=0x9000, short=0x04, short=0x03) 2 0

(byte[0x0003 STD]=0xaa09, short=0x00, byte[0x0106 GLOB]=0x9000, short=0x0e, short=0x03) 1 0

(byte[0x0004 COD]=0xa90a, short=0x00, byte[0x0106 GLOB]=0x9000, short=0x05, short=0x04) 2 0

(byte[0x0004 STD]=0xa20a, short=0x00, byte[0x0106 GLOB]=0x9000, short=0x00, short=0x04) 2 0

(byte[0x0008 COD]=0xaa0a, short=0x00, byte[0x0106 GLOB]=0x9000, short=0x02, short=0x08) 2 0

(byte[0x0008 COD]=0xaa0a, short=0x00, byte[0x0106 GLOB]=0x9000, short=0x0b, short=0x08) 2 0

(byte[0x0106 GLOB]=0x9000, short=0x07, byte[0x0004 COD]=0xa90a, short=0x00, short=0x04) 2 0

(byte[0x0106 GLOB]=0x9000, short=0x0d, byte[0x0106 GLOB]=0x9000, short=0x09, short=0x05) 2 0

javacard/framework.Util:arrayCopy (2 invocations)(byte[0x0106 GLOB]=0x9000, short=0x00, byte[0x0012 STD]=0xa50c, short=0x00, short=0x12) 1 1

(byte[0x0106 GLOB]=0x9000, short=0x00, byte[0x0012 STD]=0xa70c, short=0x00, short=0x12) 1 1

javacard/framework.Util:arrayCompare (2 invocations)(byte[0x0106 STD GLOB]=0x9000, short=0x05, byte[0x0008 COD ]=0xaa0a, short=0x00, short=0x08) 2 0

javacard/framework.Util:getShort (10 invocations)(byte[0x0004 COD]=0xa90a, short=0x00) 2 0(byte[0x0006 STD]=0xa40a, short=0x00) 2 0(byte[0x0006 STD]=0xa40a, short=0x02) 2 0(byte[0x0006 STD]=0xa40a, short=0x04) 2 0(byte[0x0106 GLOB]=0x9000, short=0x05) 2 0

javacard/framework.OwnerPIN:check (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x05, byte=0x04) 1 0

javacard/framework.Util:arrayFillNonAtomic (6 invocations)(byte[0x0008 COD]=0xaa0a, short=0x00, short=0x08, byte=0x00) 6 0

javacard/framework.AID:getBytes (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x04) 1 0

©Mesure Project, 2006-2007 page 50/68

Page 51: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

Bytecodes N Tr Bytecode. N TrSCONST_0 91 8 SLOAD_0 7 0SLOAD 90 2 SCONST_5 7 0GETFIELD_A_THIS 83 6 BASTORE [STD GLOB] 7 0ALOAD_2 81 2 SSUB 6 0INVOKESTATIC 71 6 GETFIELD_B_THIS 6 4SSTORE 59 0 DUP 6 4INVOKEVIRTUAL 38 2 ARRAYLENGTH [COD] 6 0SCONST_1 34 4 ARETURN 6 0ALOAD_1 32 0 STABLESWITCH 4 0RETURN 31 2 SLOAD_1 4 0BALOAD [STD GLOB] 30 0 PUTFIELD_B 4 4SCONST_4 28 0 IF_SCMPEQ 4 0BSPUSH 27 2 GETFIELD_B 4 4GETSTATIC_A 25 0 DUP_X 4 4IF_SCMPNE 23 4 BASTORE [COD] 4 0ALOAD_0 23 6 BALOAD [COD] 4 0POP 22 4 SLOOKUPSWITCH 3 0GOTO 19 0 SLOAD_2 3 0SLOAD_3 17 0 SINC 3 0SADD 16 4 IFNULL 3 0S2B 16 4 BALOAD [COR] 3 0SCONST_3 14 0 AALOAD [STD] 3 0IFNE 14 0 SSPUSH 2 0ALOAD 14 2 PUTFIELD_S 2 2SALOAD [COD] 12 2 IFGE 2 0ASTORE_2 12 0 GETFIELD_S_THIS 2 0SCONST_2 11 0 GETFIELD_A 2 0IF_SCMPGE 11 0 CHECKCAST 2 0SASTORE [COD] 10 0 ASTORE_1 2 0IFEQ 10 0 ASTORE 2 0SSTORE_3 9 0 ARRAYLENGTH [STD] 2 0BASTORE [COR] 9 0 SSTORE_1 1 0SALOAD [STD] 8 0 IF_SCMPLE 1 0INVOKESPECIAL 8 0 IF_SCMPGT 1 0SRETURN 7 0

Total : 1127 (ongoing transaction : 82)

©Mesure Project, 2006-2007 page 51/68

Page 52: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

6 Annex 2 – Statistics for banking application 1

API Method N Transactionjavacard/framework.Util:getShort 49 5javacard/framework.Util:arrayCopyNonAtomic 41 0javacard/framework.Util:makeShort 36 0javacard/framework.APDU:getBuffer 22 0javacard/framework.Applet:selectingApplet 11 0javacard/security.SignatureImpl:init(Key,byte, byte[],short,short) 10 0javacard/security.SignatureImpl:verify 9 0javacard/framework.APDU:setOutgoingLength 9 0javacard/framework.APDU:setOutgoing 9 0javacard/framework.APDU:sendBytesLong 9 0javacard/framework.Util:arrayCopy 7 7javacard/framework.JCSystem:commitTransaction 7 0javacard/framework.JCSystem:beginTransaction 7 0javacardx/crypto.CipherImpl:init(Key,byte) 4 0javacardx/crypto.CipherImpl:doFinal 4 0javacard/framework.Util:setShort 3 0javacard/framework.Util:arrayFillNonAtomic 3 0javacard/framework.APDU:setIncomingAndReceive 3 0javacard/security.DESKeyImpl:setKey 2 0javacard/security.SignatureImpl:sign 1 0javacard/framework.Util:arrayCompare 1 0javacard/framework.OwnerPIN:resetAndUnblock 1 0javacard/framework.OwnerPIN:check 1 0javacard/framework.APDU:setOutgoingAndSend 1 0javacard/framework.APDU:getProtocol 1 0

Total: 251 (ongoing transaction: 12)

API Method with array as parameter N TrFor each primitive type, the passed value is indicated. For each class type, the reference is indicated. For each array type, the length, the duration and the reference are respectively indicated:

• STD. A standard array of persistent duration.

• COD. An array of CLEAR ON DESELECT duration.

• COR. An array of CLEAR ON RESET duration.

• GLOB. A global array, i.e. the APDU buffer.

javacard/security.SignatureImpl:init (10 invocations)(javacard/security/Key=0xa609, byte=0x02, byte[0x0008 STD]=0xa908, short=0x00, short=0x08) 9 0

(javacard/security/Key=0xac14, byte=0x01, byte[0x000a STD]=0xa50a, short=0x00, short=0x08) 1 0

javacard/security.SignatureImpl:verify (9 invocations)(byte[0x0030 STD]=0xa70d, short=0x00, short=0x30, byte[0x0008 STD]=0xa60d, short=0x00, short=0x08) 1 0

(byte[0x0030 STD]=0xa717, short=0x00, short=0x30, byte[0x0008 STD]=0xa617, short=0x00, short=0x08) 1 0

(byte[0x0040 STD]=0xad17, short=0x00, short=0x40, byte[0x0008 STD]=0xac17, short=0x00, short=0x08) 1 0

©Mesure Project, 2006-2007 page 52/68

Page 53: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

(byte[0x0050 STD]=0xa410, short=0x00, short=0x50, byte[0x0008 STD]=0xa310, short=0x00, short=0x08) 1 0

(byte[0x0068 STD]=0xa218, short=0x00, short=0x68, byte[0x0008 STD]=0xa118, short=0x00, short=0x08) 1 0

(byte[0x0098 STD]=0xa518, short=0x00, short=0x98, byte[0x0008 STD]=0xa418, short=0x00, short=0x08) 1 0

(byte[0x0098 STD]=0xa916, short=0x00, short=0x98, byte[0x0008 STD]=0xa716, short=0x00, short=0x08) 1 0

(byte[0x00a0 STD]=0xa818, short=0x00, short=0xa0, byte[0x0008 STD]=0xa718, short=0x00, short=0x08) 1 0

(byte[0x00c8 STD]=0xa117, short=0x00, short=0xc8, byte[0x0008 STD]=0xa017, short=0x00, short=0x08) 1 0

javacardx/crypto.CipherImpl:doFinal (4 invocations)(byte[0x0106 GLOB]=0x9000, short=0x00, short=0x08, byte[0x0135 COD]=0xa209, short=0xb0) 1 0

(byte[0x0135 COD]=0xa209, short=0x34, short=0x08, byte[0x0135 COD]=0xa209, short=0x34) 2 0

(byte[0x0135 COD]=0xa209, short=0x50, short=0x10, byte[0x0135 COD]=0xa209, short=0x40) 1 0

javacard/framework.Util:arrayCopy (7 invocations)(byte[0x0001 COD]=0xa110, short=0x00, byte[0x0004 STD]=0xa010, short=0x02, short=0x01) 2 2

(byte[0x0135 COD]=0xa209, short=0x1a, byte[0x0004 STD]=0xa50e, short=0x02, short=0x02) 1 1

(byte[0x0135 COD]=0xa209, short=0x29, byte[0x0008 STD]=0xa30f, short=0x02, short=0x06) 1 1

(byte[0x0135 COD]=0xa209, short=0x50, byte[0x0005 STD]=0xaa13, short=0x02, short=0x03) 1 1

(byte[0x0135 COD]=0xa209, short=0x53, byte[0x0016 STD]=0xa811, short=0x02, short=0x14) 1 1

(byte[0x0135 COD]=0xa209, short=0x58, byte[0x0004 STD]=0xad0d, short=0x02, short=0x02) 1 1

javacard/framework.OwnerPIN:check (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x05, byte=0x08) 1 0

javacard/security.SignatureImpl:sign (1 invocation)(byte[0x0135 COD]=0xa209, short=0x80, short=0x28, byte[0x0135 COD]=0xa209, short=0x34) 1 0

javacard/framework.Util:arrayCompare (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x25, byte[0x000a STD]=0xa50a, short=0x00, short=0x00) 1 0

javacard/framework.Util:arrayFillNonAtomic (3 invocations)(byte[0x0106 GLOB]=0x9000, short=0x02, short=0x06, byte=0x00) 1 0(byte[0x0135 COD]=0xa209, short=0x10, short=0x125, byte=0xaa) 1 0(byte[0x0135 COD]=0xa209, short=0x40, short=0x10, byte=0x00) 1 0

javacard/framework.Util:setShort (3 invocations)(byte[0x0106 GLOB]=0x9000, short=0x00, short=0x01) 1 0(byte[0x0135 COD]=0xa209, short=0x1a, short=0x01) 1 0(byte[0x0135 COD]=0xa209, short=0x58, short=0x01) 1 0

©Mesure Project, 2006-2007 page 53/68

Page 54: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard/security.DESKeyImpl:setKey (2 invocations)(byte[0x0135 COD]=0xa209, short=0x0040) 1 0(byte[0x0135 COD]=0xa209, short=0x0048) 1 0

javacard/framework.Util:getShort (49 invocations)(byte[0x0003 STD]=0xa00f, short=0x00) 1 0(byte[0x0003 STD]=0xa80e, short=0x00) 2 0(byte[0x0003 STD]=0xa909, short=0x00) 14 0(byte[0x0004 STD]=0xa50e, short=0x00) 2 1(byte[0x0004 STD]=0xad0d, short=0x00) 3 1(byte[0x0005 STD]=0xaa13, short=0x00) 2 1(byte[0x0008 STD]=0xa30f, short=0x00) 2 1(byte[0x0016 STD]=0xa811, short=0x00) 1 1(byte[0x001b STD]=0xa516, short=0x00) 1 0(byte[0x0030 STD]=0xa70d, short=0x00) 1 0(byte[0x0030 STD]=0xa717, short=0x00) 1 0(byte[0x0040 STD]=0xad17, short=0x00) 1 0(byte[0x0050 STD]=0xa410, short=0x1d) 1 0(byte[0x0050 STD]=0xa410, short=0x38) 1 0(byte[0x0068 STD]=0xa218, short=0x00) 1 0(byte[0x0098 STD]=0xa518, short=0x00) 1 0(byte[0x0098 STD]=0xa916, short=0x00) 1 0(byte[0x00a0 STD]=0xa818, short=0x00) 1 0(byte[0x00c8 STD]=0xa117, short=0x00) 1 0(byte[0x0106 GLOB]=0x9000, short=0x02) 7 0(byte[0x0106 GLOB]=0x9000, short=0x11) 1 0(byte[0x0106 GLOB]=0x9000, short=0x18) 1 0(byte[0x0135 COD]=0xa209, short=0x1a) 1 0(byte[0x0135 COD]=0xa209, short=0x58) 1 0

javacard/framework.Util:arrayCopyNonAtomic (41 invocations)(byte[0x0003 STD]=0xa00f, short=0x02, byte[0x0135 COD]=0xa209, short=0x2f, short=0x01) 1 0

(byte[0x0003 STD]=0xa80e, short=0x02, byte[0x0135 COD]=0xa209, short=0x06, short=0x01) 2 0

(byte[0x0003 STD]=0xa909, short=0x02, byte[0x0135 COD]=0xa209, short=0x00, short=0x01) 14 0

(byte[0x0004 STD]=0xa50e, short=0x02, byte[0x0135 COD]=0xa209, short=0x1a, short=0x02) 1 0

(byte[0x0004 STD]=0xad0d, short=0x02, byte[0x0135 COD]=0xa209, short=0x58, short=0x02) 2 0

(byte[0x0005 STD]=0xaa13, short=0x02, byte[0x0135 COD]=0xa209, short=0x50, short=0x03) 1 0

(byte[0x0008 STD]=0xa30f, short=0x02, byte[0x0135 COD]=0xa209, short=0x29, short=0x06) 1 0

(byte[0x000a STD]=0xa710, short=0x02, byte[0x0135 COD]=0xa209, short=0x50, short=0x02) 1 0

(byte[0x000a STD]=0xa710, short=0x05, byte[0x0135 COD]=0xa209, short=0x5a, short=0x02) 1 0

(byte[0x0023 STD]=0xa40a, short=0x00, byte[0x0135 COD]=0xa209, short=0x11, short=0x23) 1 0

(byte[0x0030 STD]=0xa70d, short=0x06, byte[0x0135 COD]=0xa209, short=0x9d, short=0x02) 1 0

(byte[0x0050 STD]=0xa410, short=0x02, byte[0x0135 COD]=0xa209, short=0x07, short=0x02) 2 0

(byte[0x0106 GLOB]=0x9000, short=0x04, byte[0x0135 COD]=0xa209, short=0xb8, short=0x2c) 1 0

©Mesure Project, 2006-2007 page 54/68

Page 55: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

(byte[0x0106 GLOB]=0x9000, short=0x05, byte[0x0135 COD]=0xa209, short=0x54, short=0x06) 1 0

(byte[0x0106 GLOB]=0x9000, short=0x05, byte[0x0135 COD]=0xa209, short=0x80, short=0x1d) 1 0

(byte[0x0106 GLOB]=0x9000, short=0x18, byte[0x0135 COD]=0xa209, short=0x5a, short=0x05) 1 0

(byte[0x0106 GLOB]=0x9000, short=0x23, byte[0x0135 COD]=0xa209, short=0x27, short=0x02) 1 0

(byte[0x0135 COD]=0xa209, short=0x11, byte[0x0106 GLOB]=0x9000, short=0x01, short=0x0b) 1 0

(byte[0x0135 COD]=0xa209, short=0x1c, byte[0x0106 GLOB]=0x9000, short=0x17, short=0x15) 1 0

(byte[0x0135 COD]=0xa209, short=0x21, byte[0x0135 COD]=0xa209, short=0x61, short=0x06) 1 0

(byte[0x0135 COD]=0xa209, short=0x21, byte[0x0135 COD]=0xa209, short=0xa1, short=0x06) 1 0

(byte[0x0135 COD]=0xa209, short=0x31, byte[0x0106 GLOB]=0x9000, short=0x0c, short=0x0b) 1 0

(byte[0x0135 COD]=0xa209, short=0x34, byte[0x0135 COD]=0xa209, short=0x78, short=0x08) 1 0

(byte[0x0135 COD]=0xa209, short=0x50, byte[0x0135 COD]=0xa209, short=0x58, short=0x08) 1 0

(byte[0x0135 COD]=0xa209, short=0x99, byte[0x0135 COD]=0xa209, short=0x54, short=0x04) 1 0

javacard/framework.APDU:sendBytesLong (9 invocations)(byte[0x001b STD]=0xa516, short=0x02, short=0x19) 1 0(byte[0x0030 STD]=0xa70d, short=0x02, short=0x18) 1 0(byte[0x0030 STD]=0xa717, short=0x02, short=0x29) 1 0(byte[0x0040 STD]=0xad17, short=0x02, short=0x39) 1 0(byte[0x0068 STD]=0xa218, short=0x02, short=0x64) 1 0(byte[0x0098 STD]=0xa518, short=0x02, short=0x96) 1 0(byte[0x0098 STD]=0xa916, short=0x02, short=0x91) 1 0(byte[0x00a0 STD]=0xa818, short=0x02, short=0x97) 1 0(byte[0x00c8 STD]=0xa117, short=0x02, short=0xc3) 1 0

©Mesure Project, 2006-2007 page 55/68

Page 56: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

Bytecodes N Tr Bytecode. N TrGETFIELD_A_THIS 928 128 SLOAD_0 48 0SLOAD_2 609 116 ALOAD 47 0BSPUSH 568 14 SALOAD [STD] 43 0SLOAD_1 344 58 SSTORE_3 37 0SLOAD 330 2 SSHL 36 0IF_SCMPLT 316 58 SCONST_3 36 0BALOAD [STD] 302 51 SCONST_4 34 0SCONST_0 299 19 IF_SCMPLE 27 0S2B 265 51 IFNE 25 0ARRAYLENGTH [STD] 253 58 DUP2 15 0SSTORE_1 244 58 SSUB 14 0SINC 242 51 IFEQ_W 14 0INVOKESTATIC 231 19 BASTORE [COR] 14 0IF_SCMPNE 218 7 ASTORE_2 14 0SXOR 204 51 SLOOKUPSWITCH 11 0INVOKEVIRTUAL 186 0 SCONST_5 11 0SRETURN 183 7 SDIV 10 0ALOAD_0 170 14 AALOAD [STD] 9 0SSTORE 148 0 SCONST_M1 8 0ALOAD_1 146 7 IF_SCMPGT 7 0SCONST_2 144 5 IFGE_W 7 0SADD 134 0 IFGE 7 0RETURN 124 7 BASTORE [STD] 7 7INVOKESPECIAL 124 14 ASTORE_3 7 0SAND 112 0 ARETURN 7 0SLOAD_3 111 2 IFLE 6 0BALOAD [COD] 101 0 SOR 5 0ALOAD_2 97 0 CHECKCAST 4 0IFEQ 96 0 IFNULL 3 0POP 92 7 BALOAD [COR] 3 0GETFIELD_B_THIS 91 7 ASTORE 3 0BALOAD [STD GLOB] 91 0 INVOKEINTERFACE 2 0SCONST_1 90 0 IF_SCMPNE_W 2 0IF_SCMPEQ 82 0 GOTO_W 2 0GETSTATIC_A 82 0 SMUL 1 0GOTO 75 14 RET 1 0SSPUSH 72 0 PUTFIELD_A 1 0GETFIELD_A 57 0 JSR 1 0SSTORE_2 56 7 IF_ACMPNE 1 0BASTORE [COD] 55 0 ARRAYLENGTH [COD] 1 0ALOAD_3 53 0

Total : 8656 (ongoing transaction : 839)

©Mesure Project, 2006-2007 page 56/68

Page 57: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

7 Annex 3 – Statistics for banking application 2

API Method N Transactionjavacard/framework.Util:getShort 27 0javacard/framework.APDU:getBuffer 26 0javacard/framework.Util:setShort 17 0javacard/framework.Util:arrayCopyNonAtomic 16 0javacard/framework.APDU:getProtocol 13 0javacard/framework.APDU:setOutgoingLength 8 0javacard/framework.APDU:setOutgoing 8 0javacard/framework.APDU:sendBytesLong 8 0javacard/framework.Util:arrayCompare 6 0javacard/security.SignatureImpl:sign 4 0javacard/framework.Util:arrayFillNonAtomic 4 0javacard/framework.APDU:setOutgoingAndSend 4 0javacard/framework.APDU:setIncomingAndReceive 4 0javacard/security.SignatureImpl:init(Key,byte) 2 0javacard/security.SignatureImpl:init(Key,byte,byte[],short,short) 2 0javacard/security.DESKeyImpl:setKey 2 0javacard/security.DESKeyImpl:getKey 2 0javacard/framework.Util:makeShort 2 0javacard/framework.Util:arrayCopy 1 0javacard/framework.OwnerPIN:getTriesRemaining 1 0javacard/framework.OwnerPIN:check 1 0javacard/framework.JCSystem:getAID 1 0javacard/framework.Applet:selectingApplet 1 0javacard/framework.Applet:select 1 0javacard/framework.AID:getBytes 1 0

Total: 162 (ongoing transaction: 0)

API Method with array as parameter

For each primitive type, the passed value is indicated. For each class type, the reference is indicated. For each array type, the length, the duration and the reference are respectively indicated:

STD. A standard array of persistent duration.

COD. An array of CLEAR ON DESELECT duration.

COR. An array of CLEAR ON RESET duration.

GLOB. A global array, i.e. the APDU buffer.

N Tr

javacard/security.DESKeyImpl:getKey (2 invocations) (byte[0x003c COD ]=0xa00c, short=0x0000) 2 0

javacard/security.SignatureImpl:init (2 invocations)(javacard/security/Key=0xa509, byte=0x01, byte[0x003c COD ]=0xa00c, short=0x00, short=0x08) 2 0

javacard/framework.Util:arrayCopy (1 invocation)(byte[0x0106 STD GLOB]=0x9000, short=0x05, byte[0x0008 COD ]=0xad09, short=0x00, short=0x08) 1 0

©Mesure Project, 2006-2007 page 57/68

Page 58: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard/framework.AID:getBytes (1 invocation)(byte[0x0106 STD GLOB]=0x9000, short=0x00) 1 0

javacard/framework.OwnerPIN:check (1 invocation)(byte[0x0106 STD GLOB]=0x9000, short=0x05, byte=0x08) 1 0

javacard/security.SignatureImpl:sign (4 invocations)(byte[0x0106 STD GLOB]=0x9000, short=0x05, short=0x20, byte[0x003c COD ]=0xa00c, short=0x00) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x07, short=0x20, byte[0x003c COD ]=0xa00c, short=0x00) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x25, short=0x08, byte[0x003c COD ]=0xa00c, short=0x00) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x27, short=0x08, byte[0x003c COD ]=0xa00c, short=0x00) 1 0

javacard/framework.Util:arrayCompare (6 invocations)(byte[0x000c COD ]=0xac09, short=0x00, byte[0x000c STD ]=0xa70f, short=0x00, short=0x0c) 1 0

(byte[0x002b STD ]=0xa60c, short=0x18, byte[0x0106 STD GLOB]=0x9000, short=0x07, short=0x02) 1 0

(byte[0x002b STD ]=0xa60c, short=0x18, byte[0x0106 STD GLOB]=0x9000, short=0x11, short=0x02) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x10, byte[0x002b STD ]=0xa60c, short=0x14, short=0x02) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x18, byte[0x002b STD ]=0xa60c, short=0x14, short=0x02) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x18, byte[0x002b STD ]=0xa60c, short=0x16, short=0x02) 1 0

javacard/framework.Util:arrayFillNonAtomic (4 invocations)(byte[0x002b STD ]=0xa60c, short=0x03, short=0x03, byte=0x00) 1 0(byte[0x008c STD ]=0xa90f, short=0x00, short=0x0e, byte=0x00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x2a, short=0x03, byte=0x00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x2c, short=0x03, byte=0x00) 1 0

javacard/framework.Util:setShort (17 invocations)(byte[0x008c STD ]=0xa90f, short=0x0c, short=0x01) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x02, short=0x5c00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x03, short=0x01) 2 0(byte[0x0106 STD GLOB]=0x9000, short=0x1d, short=0x8407) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x22, short=0x5c00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x24, short=0x01) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x24, short=0x5c00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x26, short=0x01) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x27, short=0x50) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x35, short=0x9f38) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x3b, short=0x5f2d) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x46, short=0x9f12) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x58, short=0xbf0c) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x60, short=0x8701) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x63, short=0x9f11) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x65, short=0x101) 1 0

javacard/security.DESKeyImpl:setKey (2 invocations)(byte[0x003c COD ]=0xa00c, short=0x0000) 2 0

©Mesure Project, 2006-2007 page 58/68

Page 59: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard/framework.Util:getShort (27 invocations)(byte[0x0106 STD GLOB]=0x9000, short=0x00) 13 0(byte[0x0106 STD GLOB]=0x9000, short=0x02) 13 0(byte[0x0106 STD GLOB]=0x9000, short=0x05) 1 0

javacard/framework.Util:arrayCopyNonAtomic (16 invocations)(byte[0x0003 STD ]=0xa20f, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x38, short=0x03) 1 0

(byte[0x0005 STD ]=0xa50f, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x5b, short=0x05) 1 0

(byte[0x0008 STD ]=0xa30f, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x3e, short=0x08) 1 0

(byte[0x000b STD ]=0xa10f, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x2a, short=0x0b) 1 0

(byte[0x000f STD ]=0xa40f, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x49, short=0x0f) 1 0

(byte[0x0014 STD ]=0xa90c, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x04, short=0x14) 1 0

(byte[0x002b STD ]=0xa60c, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x0e, short=0x06) 2 0

(byte[0x002b STD ]=0xa60c, short=0x02, byte[0x0106 STD GLOB]=0x9000, short=0x26, short=0x04) 1 0

(byte[0x002b STD ]=0xa60c, short=0x02, byte[0x0106 STD GLOB]=0x9000, short=0x28, short=0x04) 1 0

(byte[0x003c COD ]=0xa00c, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x05, short=0x08) 2 0

(byte[0x0106 STD GLOB]=0x9000, short=0x00, byte[0x0106 STD GLOB]=0x9000, short=0x1f, short=0x07) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x07, byte[0x008c STD ]=0xa90f, short=0x01, short=0x06) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x1a, byte[0x008c STD ]=0xa90f, short=0x07, short=0x02) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x1c, byte[0x008c STD ]=0xa90f, short=0x09, short=0x03) 1 0

javacard/framework.APDU:sendBytesLong (8 invocations)(byte[0x000a STD ]=0xa00f, short=0x00, short=0x0a) 1 0(byte[0x0016 STD ]=0xad0e, short=0x00, short=0x16) 1 0(byte[0x0027 STD ]=0xa70e, short=0x00, short=0x27) 1 0(byte[0x002f STD ]=0xa90e, short=0x00, short=0x2f) 1 0(byte[0x003e STD ]=0xab0e, short=0x00, short=0x3e) 1 0(byte[0x0045 STD ]=0xac0e, short=0x00, short=0x45) 1 0(byte[0x0086 STD ]=0xa80e, short=0x00, short=0x86) 1 0(byte[0x0086 STD ]=0xaa0e, short=0x00, short=0x86) 1 0

©Mesure Project, 2006-2007 page 59/68

Page 60: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

Bytecodes N Tr Bytecode. N TrSLOAD 708 0 BASTORE [COD] 36 0ALOAD_1 259 0 SLOOKUPSWITCH 35 0BSPUSH 254 0 SCONST_M1 33 0SCONST_0 236 0 IF_SCMPLE 33 0SSTORE 233 0 ARETURN 32 0SAND 226 0 SSHR 31 0SCONST_1 217 0 GETFIELD_S_THIS 28 0GETFIELD_A_THIS 215 0 IFNULL 25 0BALOAD [STD] 199 0 SLOAD_0 24 0SLOAD_1 193 0 PUTFIELD_B 24 0ALOAD_0 182 0 ASTORE_2 24 0GETFIELD_B_THIS 177 0 BASTORE [STD GLOB] 22 0SADD 159 0 SCONST_5 20 0IFEQ 159 0 DUP 19 0ALOAD_2 158 0 IF_SCMPGT 16 0INVOKEVIRTUAL 152 0 BASTORE [COR] 16 0IF_SCMPNE 146 0 SSHL 15 0INVOKESTATIC 142 0 SSTORE_2 14 0SSPUSH 135 0 IFGE 13 0GETSTATIC_A 132 0 CHECKCAST 13 0ALOAD_3 120 0 BASTORE [STD] 13 0SRETURN 118 0 SSTORE_1 12 0S2B 116 0 BALOAD [COD] 12 0SLOAD_2 114 0 SOR 11 0SLOAD_3 113 0 DUP2 11 0BALOAD [STD GLOB] 103 0 ASTORE_3 9 0SINC 102 0 ASTORE 7 0GOTO 99 0 IFLT 6 0SSUB 91 0 GETFIELD_B 6 0IF_SCMPLT 91 0 INVOKEINTERFACE 4 0RETURN 85 0 IF_SCMPNE_W 4 0SCONST_2 82 0 BALOAD [COR] 3 0IFNE 81 0 SREM 2 0AALOAD [STD] 78 0 IFNONNULL 2 0INVOKESPECIAL 74 0 IFLE 2 0ARRAYLENGTH [STD] 64 0 GOTO_W 2 0SCONST_3 62 0 DUP_X 2 0SSTORE_3 61 0 SMUL 1 0SASTORE [STD] 60 0 PUTFIELD_S 1 0ALOAD 58 0 PUTFIELD_A 1 0IF_SCMPEQ 57 0 IF_SCMPGE 1 0SCONST_4 50 0 IFNE_W 1 0SALOAD [STD] 43 0 IFEQ_W 1 0POP 37 0

Total : 6828 (ongoing transaction : 0)

©Mesure Project, 2006-2007 page 60/68

Page 61: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

8 Annex 4 – Statistics for transport application

API Methods N Transactionjavacard/framework.Util:arrayCopy 12 1javacard/framework.APDU:getBuffer 7 0javacard/framework.Util:setShort 6 0javacard/framework.APDU:setOutgoingAndSend 5 0javacard/framework.Util:getShort 4 0javacard/framework.APDU:setIncomingAndReceive 4 0javacard/framework.Util:arrayFillNonAtomic 3 0javacardx/crypto.CipherImpl:init(Key,byte) 1 0javacardx/crypto.CipherImpl:doFinal 1 0javacard/security.DESKeyImpl:setKey 1 0javacard/security.DESKeyImpl:getKey 1 0javacard/framework.Util:arrayCopyNonAtomic 1 0javacard/framework.Util:arrayCompare 1 0javacard/framework.JCSystem:getAID 1 0javacard/framework.JCSystem:commitTransaction 1 0javacard/framework.JCSystem:beginTransaction 1 0javacard/framework.APDU:getProtocol 1 0javacard/framework.AID:partialEquals 1 0

Total: 52 (ongoing transaction: 1)

API Method with array as parameter N Tr

For each primitive type, the passed value is indicated. For each class type, the reference is indicated. For each array type, the length, the duration and the reference are respectively indicated:

• STD. A standard array of persistent duration.

• COD. An array of CLEAR ON DESELECT duration.

• COR. An array of CLEAR ON RESET duration.

• GLOB. A global array, i.e. the APDU buffer.

javacard/security.DESKeyImpl:getKey (1 invocation)(byte[0x0018 COD]=0xab0c, short=0x0000) 1 0

javacardx/crypto.CipherImpl:doFinal (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x09, short=0x08, byte[0x0106 GLOB]=0x9000, short=0x09) 1 0

javacard/framework.Util:arrayCopy (12 invocations)(byte[0x0018 COD]=0xab0c, short=0x00, byte[0x0018 COD]=0xab0c, short=0x10, short=0x08) 1 0

(byte[0x0018 COD ]=0xab0c, short=0x08, byte[0x0018 COD]=0xab0c, short=0x00, short=0x08) 1 0

(byte[0x0024 STD]=0xa209, short=0x00, byte[0x0106 GLOB]=0x9000, short=0x00, short=0x24) 1 0

(byte[0x0060 COD]=0xa409, short=0x00, byte[0x0300 STD]=0xad08, short=0x100, short=0x20) 1 1

(byte[0x0106 GLOB]=0x9000, short=0x00, byte[0x0200 COD]=0xac0c, short=0x28, short=0x24) 1 0

(byte[0x0106 GLOB]=0x9000, short=0x00, byte[0x0200 COD]=0xac0c, short=0x4c, short=0x24) 1 0

©Mesure Project, 2006-2007 page 61/68

Page 62: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

(byte[0x0106 GLOB]=0x9000, short=0x00, byte[0x0200 COD]=0xac0c, short=0x70, short=0x24) 1 0

(byte[0x0106 GLOB]=0x9000, short=0x05, byte[0x0200 COD]=0xac0c, short=0x02, short=0x26) 1 0

(byte[0x0300 STD]=0xad08, short=0x03, byte[0x0106 GLOB]=0x9000, short=0x0e, short=0x1d) 1 0

(byte[0x0300 STD]=0xad08, short=0x100, byte[0x0060 COD]=0xa409, short=0x00, short=0x20) 1 0

(byte[0x0300 STD]=0xad08, short=0x43, byte[0x0106 GLOB]=0x9000, short=0x05, short=0x1d) 1 0

(byte[0x0300 STD]=0xad08, short=0xe3, byte[0x0106 GLOB]=0x9000, short=0x05, short=0x1d) 1 0

javacard/framework.Util:arrayCompare (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x05, byte[0x0106 GLOB]=0x9000, short=0x09, short=0x04) 1 0

javacard/framework.AID:partialEquals (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x05, byte=0x08) 1 0

javacard/framework.Util:arrayFillNonAtomic (3 invocations)(byte[0x0010 COD]=0xa309, short=0x00, short=0x10, byte=0x00) 2 0(byte[0x0060 COD]=0xa409, short=0x00, short=0x60, byte=0x00) 1 0

javacard/framework.Util:setShort (6 invocations)(byte[0x0106 GLOB]=0x9000, short=0x0a, short=0x3acf) 1 0(byte[0x0106 GLOB]=0x9000, short=0x0c, short=0x3d09) 1 0(byte[0x0200 COD ]=0xac0c, short=0x00, short=0x28) 1 0(byte[0x0200 COD ]=0xac0c, short=0x00, short=0x4c) 1 0(byte[0x0200 COD ]=0xac0c, short=0x00, short=0x70) 1 0(byte[0x0200 COD ]=0xac0c, short=0x00, short=0x94) 1 0

javacard/security.DESKeyImpl:setKey (1 invocation)(byte[0x0018 COD]=0xab0c, short=0x0008) 1 0

javacard/framework.Util:getShort (4 invocations)(byte[0x0200 COD]=0xac0c, short=0x00) 4 0

javacard/framework.Util:arrayCopyNonAtomic (1 invocation)(byte[0x0106 GLOB]=0x9000, short=0x05, byte[0x0060 COD]=0xa409, short=0x03, short=0x1d) 1 0

©Mesure Project, 2006-2007 page 62/68

Page 63: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

Bytecodes N Tr Bytecode. N TrSLOAD 6106 0 SLOAD_0 16 0SADD 3906 3 IF_SCMPNE 15 0SSTORE 2738 0 IF_SCMPLE 11 0SCONST_0 2562 2 SLOOKUPSWITCH 10 2GETFIELD_A_THIS 2514 0 SLOAD_1 10 2SCONST_1 1523 3 DUP2 10 0BALOAD [COD] 1508 5 ASTORE_2 9 0DUP 1477 0 IF_SCMPEQ 8 0S2B 1385 0 ALOAD_3 8 0SSUB 1343 0 SRETURN 7 0GETSTATIC_A 1230 3 IF_SCMPNE_W 7 0IFNE 1203 2 BASTORE [COR] 7 0SAND 1190 0 SMUL 6 0SSPUSH 1187 1 SSHR 5 0BALOAD [STD] 1184 0 SSHL 5 1BASTORE [COD] 1181 0 SALOAD [STD] 4 0BSPUSH 247 4 STABLESWITCH 3 0SLOAD_3 179 6 IFNULL 3 0ALOAD_1 167 0 IFLT 3 0SSTORE_3 156 1 GETFIELD_B_THIS 3 0IFGE 153 0 ARRAYLENGTH [COD] 3 0SLOAD_2 151 0 SINC 2 1SSTORE_2 148 0 INVOKEINTERFACE 2 0ALOAD 93 1 IFLT_W 2 0ALOAD_2 80 5 GETSTATIC_B 2 0BALOAD [STD GLOB] 51 0 BASTORE [STD] 2 1INVOKESTATIC 36 2 ASTORE_3 2 0SCONST_2 35 0 ALOAD_0 2 0INVOKEVIRTUAL 33 0 SOR 1 0BASTORE [STD GLOB] 30 0 RET 1 0RETURN 26 0 JSR 1 0IF_SCMPLT 24 2 IF_SCMPGE 1 0SCONST_4 22 0 IFLE 1 0SCONST_3 22 0 IFGT 1 0ASTORE 22 1 IFEQ_W 1 0POP 20 1 GOTO_W 1 0SCONST_5 19 1 CHECKCAST 1 0IFEQ 17 1 ARRAYLENGTH [STD] 1 0GOTO 17 2 ACONST_NULL 1 0SXOR 16 0

Total : 34179 (ongoing transaction : 53)

©Mesure Project, 2006-2007 page 63/68

Page 64: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

9 Annex 5 – Statistics for CardEdge application (MuscleCard)

See [CARDEDGE].

API Method N Transactionjavacard/framework.Util:getShort 72 0javacard/framework.Util:setShort 22 0javacard/framework.OwnerPIN:reset 8 0javacard/framework.Util:arrayCopyNonAtomic 5 0javacard/framework.APDU:getBuffer 5 0javacard/framework.APDU:setIncomingAndReceive 4 0javacard/framework.Util:makeShort 3 0javacard/framework.APDU:setOutgoingAndSend 3 0javacard/security.KeyImpl:getSize 2 0javacard/framework.Util:arrayFillNonAtomic 2 0javacardx/crypto.CipherImpl:init(Key,byte) 1 0javacardx/crypto.CipherImpl:doFinal 1 0javacard/security.RSAPublicKeyImpl:setModulus 1 0javacard/security.RSAPublicKeyImpl:setExponent 1 0javacard/security.KeyImpl:getType 1 0javacard/security.KeyImpl:clearKey 1 0javacard/framework.Util:arrayCopy 1 0javacard/framework.OwnerPIN:getTriesRemaining 1 0javacard/framework.OwnerPIN:check 1 0javacard/framework.JCSystem:getAID 1 0javacard/framework.Applet:selectingApplet 1 0javacard/framework.APDU:getOutBlockSize 1 0javacard/framework.AID:getBytes 1 0

Total: 139 (ongoing transaction: 0)

API Method with array as parameter

For each primitive type, the passed value is indicated. For each class type, the reference is indicated. For each array type, the length, the duration and the reference are respectively indicated:

• STD. A standard array of persistent duration.

• COD. An array of CLEAR ON DESELECT duration.

• COR. An array of CLEAR ON RESET duration.

• GLOB. A global array, i.e. the APDU buffer.

N Tr

javacard/security.RSAPublicKeyImpl:setExponent (1 invocation)(byte[0x2710 STD ]=0xa00f, short=0x009a, short=0x0003) 1 0

javacard/security.RSAPublicKeyImpl:setModulus (1 invocation)(byte[0x2710 STD ]=0xa00f, short=0x0018, short=0x0080) 1 0

javacardx/crypto.CipherImpl:doFinal (1 invocation)(byte[0x0106 STD GLOB]=0x9000, short=0x08, short=0x80, byte[0x2710 STD ]=0xa00f, short=0xb1) 1 0

©Mesure Project, 2006-2007 page 64/68

Page 65: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

javacard/framework.Util:arrayCopy (1 invocation)(byte[0x0006 STD ]=0xa20f, short=0x00, byte[0x2710 STD ]=0xa00f, short=0xa5, short=0x06) 1 0

javacard/framework.AID:getBytes (1 invocation)(byte[0x0106 STD GLOB]=0x9000, short=0x09) 1 0

javacard/framework.OwnerPIN:check (1 invocation)(byte[0x0008 STD ]=0xa90b, short=0x00, byte=0x08) 1 0

javacard/framework.Util:arrayFillNonAtomic (2 invocations)(byte[0x2710 STD ]=0xa00f, short=0x9f, short=0x25a9, byte=0x00) 1 0(byte[0x2710 STD ]=0xa00f, short=0x9f, short=0x82, byte=0x00) 1 0

javacard/framework.Util:setShort (22 invocations)(byte[0x0006 STD ]=0xa20f, short=0x00, short=0x01) 1 0(byte[0x0006 STD ]=0xa20f, short=0x02, short=0x01) 1 0(byte[0x0006 STD ]=0xa20f, short=0x04, short=0x01) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x00, short=0xfffe) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x02, short=0x00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x04, short=0x00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x06, short=0x8b) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x0e, short=0x00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x1a, short=0x400) 1 0(byte[0x2710 STD ]=0xa00f, short=0x131, short=0x2527) 1 0(byte[0x2710 STD ]=0xa00f, short=0x133, short=0x2673) 1 0(byte[0x2710 STD ]=0xa00f, short=0x9d, short=0x25bb) 2 0(byte[0x2710 STD ]=0xa00f, short=0x9d, short=0x94) 1 0(byte[0x2710 STD ]=0xa00f, short=0x9f, short=0x02) 1 0(byte[0x2710 STD ]=0xa00f, short=0x9f, short=0x2673) 1 0(byte[0x2710 STD ]=0xa00f, short=0xa1, short=0xffff) 1 0(byte[0x2710 STD ]=0xa00f, short=0xa3, short=0xffff) 1 0(byte[0x2710 STD ]=0xa00f, short=0xab, short=0x01) 1 0(byte[0x2710 STD ]=0xa00f, short=0xad, short=0x25a9) 1 0(byte[0x2710 STD ]=0xa00f, short=0xad, short=0x82) 1 0(byte[0x2710 STD ]=0xa00f, short=0xaf, short=0x80) 1 0

javacard/framework.Util:getShort (72 invocations)(byte[0x0106 STD GLOB]=0x9000, short=0x00) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x06) 1 0(byte[0x0106 STD GLOB]=0x9000, short=0x08) 1 0(byte[0x2710 STD ]=0xa00f, short=0x02) 6 0(byte[0x2710 STD ]=0xa00f, short=0x04) 14 0(byte[0x2710 STD ]=0xa00f, short=0x06) 9 0(byte[0x2710 STD ]=0xa00f, short=0x0c) 2 0(byte[0x2710 STD ]=0xa00f, short=0x0e) 1 0(byte[0x2710 STD ]=0xa00f, short=0x10) 2 0(byte[0x2710 STD ]=0xa00f, short=0x131) 2 0(byte[0x2710 STD ]=0xa00f, short=0x133) 1 0(byte[0x2710 STD ]=0xa00f, short=0x14) 2 0(byte[0x2710 STD ]=0xa00f, short=0x16) 1 0(byte[0x2710 STD ]=0xa00f, short=0x265a) 4 0(byte[0x2710 STD ]=0xa00f, short=0x265c) 5 0(byte[0x2710 STD ]=0xa00f, short=0x265e) 1 0(byte[0x2710 STD ]=0xa00f, short=0x2673) 1 0(byte[0x2710 STD ]=0xa00f, short=0x2675) 2 0(byte[0x2710 STD ]=0xa00f, short=0x98) 1 0

©Mesure Project, 2006-2007 page 65/68

Page 66: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

(byte[0x2710 STD ]=0xa00f, short=0x9d) 4 0(byte[0x2710 STD ]=0xa00f, short=0x9f) 3 0(byte[0x2710 STD ]=0xa00f, short=0xa1) 3 0(byte[0x2710 STD ]=0xa00f, short=0xa3) 3 0(byte[0x2710 STD ]=0xa00f, short=0xad) 2 0

javacard/framework.Util:arrayCopyNonAtomic (5 invocations)(byte[0x0106 STD GLOB]=0x9000, short=0x05, byte[0x0008 STD ]=0xa90b, short=0x00, short=0x08) 1 0

(byte[0x0106 STD GLOB]=0x9000, short=0x08, byte[0x0106 STD GLOB]=0x9000, short=0x11, short=0x08) 1 0

(byte[0x2710 STD ]=0xa00f, short=0x08, byte[0x0106 STD GLOB]=0x9000, short=0x08, short=0x06) 1 0

(byte[0x2710 STD ]=0xa00f, short=0x266a, byte[0x0106 STD GLOB]=0x9000, short=0x1c, short=0x09) 1 0

(byte[0x2710 STD ]=0xa00f, short=0xaf, byte[0x0106 STD GLOB]=0x9000, short=0x00, short=0x82) 1 0

©Mesure Project, 2006-2007 page 66/68

Page 67: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

Bytecodes N Tr Bytecode. N TrGETFIELD_A_THIS 217 0 GETFIELD_B_THIS 13 0SLOAD_1 192 0 SCONST_3 12 0SLOAD_3 169 0 IFNULL 12 0SLOAD 145 0 SINC 11 0INVOKEVIRTUAL 137 0 PUTFIELD_S 11 0SADD 128 0 STABLESWITCH 10 0INVOKESTATIC 127 0 BASTORE [COR] 8 0SLOAD_2 120 0 SSTORE_2 7 0SRETURN 99 0 BASTORE [STD GLOB] 7 0IF_SCMPNE 89 0 ALOAD_3 7 0BSPUSH 82 0 INVOKEINTERFACE 6 0SSTORE 80 0 SLOOKUPSWITCH 5 0SCONST_M1 71 0 SCONST_5 5 0SCONST_2 69 0 GOTO_W 5 0ALOAD_2 68 0 ASTORE_2 5 0SCONST_0 67 0 ASTORE 5 0SSTORE_3 55 0 SSHL 4 0RETURN 53 0 BALOAD [STD] 4 0ALOAD_0 51 0 ASTORE_3 4 0IFNE 45 0 SSPUSH 3 0BALOAD [STD GLOB] 43 0 SAND 3 0GOTO 41 0 IF_SCMPLE 3 0GETFIELD_S_THIS 38 0 IFNONNULL 3 0SCONST_1 37 0 GETSTATIC_B 3 0POP 32 0 DUP 3 0SCONST_4 27 0 CHECKCAST 3 0GETSTATIC_A 27 0 BALOAD [COR] 3 0ALOAD_1 27 0 SDIV 2 0ALOAD 26 0 PUTFIELD_B 2 0IFEQ 23 0 PUTFIELD_A 2 0INVOKESPECIAL 22 0 IFLE 2 0SSUB 19 0 ACONST_NULL 2 0SSTORE_1 19 0 SREM 1 0SLOAD_0 18 0 SOR 1 0IF_SCMPGE 18 0 SMUL 1 0IF_SCMPEQ 18 0 PUTSTATIC_A 1 0AALOAD [STD] 18 0 NEWARRAY 1 0IF_SCMPLT 17 0 IFLT 1 0

©Mesure Project, 2006-2007 page 67/68

Page 68: Fonctionalities - Inriamesure.gforge.inria.fr/pub/documents/F2.1 Functionalities 1.0.pdf · Each Java Card application needs to defined a specific installation method. When run, this

F2.1 Functionalities

Bytecodes N Tr Bytecode. N TrARETURN 16 0 GETFIELD_S 1 0S2B 14 0

Total : 2746 (ongoing transaction : 0)

©Mesure Project, 2006-2007 page 68/68