The Detailed Performance Analysis of Javacard Cryptographic Smartcards

Masaryk University Faculty of Informatics

The detailed performance analysis of JavaCard cryptographic smartcards

Bachelor’s Thesis

Rudolf Kvašňovský

Brno, Spring 2016 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author. Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Rudolf Kvašňovský

Advisor: RNDr. Petr Švenda Ph.D. Acknowledgement

Thank you all who stand beside me. Mainly to my fiancée, family and supportive friends. Many thanks to Petr Švenda, for an inspiration, motivation and assistance. It was worth it!

i Abstract

This thesis explores performance measuring of smart cards running the JavaCard platform. It presents JCAlgTest tool which measures various smart card attributes. Thesis brings new types of result presentation for a better card comparison. They are described together with the performance analysis of 20 different Java cards from 7 manufacturers. Analysis of RSA keys generated on-card with the focus on properties of factors of p − 1 and p + 1 is presented at the end.

ii Keywords smart card, javacard, performance testing, jcalgtest, rsa factorization

iii Contents

1 Introduction ...... 1 2 JavaCard platform ...... 2 2.1 Smart cards ...... 2 2.2 JavaCard Specifications ...... 3 2.2.1 JavaCard limitations ...... 3 2.2.2 Applet development and communication . . . .4 2.3 Cryptography provided by JavaCard ...... 4 2.3.1 Random data ...... 5 2.3.2 Hash functions ...... 5 2.3.3 Symmetric cryptography ...... 5 2.3.4 Asymmetric cryptography ...... 5 3 Measuring the performance of JavaCard ...... 6 3.1 Performance testing ...... 6 3.2 Purpose of measurement ...... 7 3.3 Related Work ...... 8 3.4 Measuring the execution time - Power analysis ...... 9 3.5 Measuring the execution time - Averaging results ...... 11 4 JCAlgTest ...... 13 4.1 Project overview ...... 14 4.1.1 History ...... 14 4.1.2 Current state and plans ...... 14 4.2 Algorithm support – JCSupport ...... 15 4.2.1 List of tested properties ...... 16 4.3 Performance testing – JCAlgTest ...... 16 5 Performance analysis ...... 19 5.1 List of measured Java cards ...... 20 5.2 Development ...... 21 5.3 Run time information tables ...... 21 5.3.1 Number of executed tests ...... 22 5.4 Comparative table ...... 23 5.5 Overall performance visualisation ...... 24 5.5.1 Overall performance comparison ...... 24 5.6 Data length dependency graph ...... 26 5.7 Performance similarity table ...... 26 5.8 Conclusions and recommendations ...... 28 iv 6 RSA key analysis ...... 30 6.1 Factorization of p-1 ...... 30 6.2 Factorization of p+1 ...... 32 7 Summary ...... 34 7.1 Proposed future work ...... 34 Bibliography ...... 35 Index ...... 38 A Data attachment ...... 38

v 1 Introduction

At the first glance, smart cards look like inconspicuous simple objects. Actually, they contain an integrated circuit - chip that can securely store and process data in different ways. They have a broad range of applications, wherever the authentication, secure data storage or digital signatures are required. Smart cards vary according to the purpose for which they were made. They can differ in an algorithm support and in performance, in the same way as standard computers. The JavaCard platform is one of the operating systems which con- trols the run of application on a smart card. We introduce the JavaCard Specifications in Chapter 2 with a summary of platform limitations, smart card communication and a coverage of cryptographic algorithms. Performance is a relevant aspect while choosing a suitable smart card. Chapter 3 contains information about JavaCard performance measuring. We specify issues connected to this topic and describe two possible solutions how to measure the operation time of particular algorithm executed on card. JCAlgTest project is extended as a part of this thesis. This tool can gather various properties from smart cards and execute performance testing. Project overview, current state, future plans and detail information are described in Chapter 4. Performance analysis, the main aim of this thesis, discusses the performance of 20 different cards from 7 manufacturers. We implement new performance results presentation and demonstrate it in Chapter 5. The outcome allows comparing the cards performance from several perspectives. The second part of the work considers RSA keys analysis. We focus on attributes of p − 1 and p + 1 factors of generated key pairs on a card. We reveal which cards meet recommendations about RSA key generation defined by standards FIPS 186-4 [1] or ANSI X9.31 [2]. Observations are available in Chapter 6.

1 2 JavaCard platform

Before the occurrence of multi-application smart cards, each application was written for a card-specific operating system and burned into read-only memory. There was almost no flexibility to change any of these components without new software or hardware implementation. Smart cards were, therefore, inflexible and difficult to program for. Multi-application platforms with portable binaries has provided a solution. JavaCard1 is being one of these.

2.1 Smart cards

Smart cards, tiny devices with embedded integrated circuits, have a wide range of application, wherever the authentication, secure data storage or application processing are necessary. ISO 7816 standard describes smart cards in overall from physical properties to communication protocol [3]. Tamper-resistant smart card contains following components: ∙ Processor – from 8 to 32-bit, running usually at 5 – 30 MHz. ∙ Cryptographic co-processor – optional component, provides support for fast execution of cryptographic algorithms. ∙ Read Only Memory (ROM) – contains the Chip Operating Sys- tem (COS), permanently burned by manufacturer. ∙ Random Access Memory (RAM) – volatile type of memory, size is only few bytes (< 10 kB). ∙ Application Memory – stores information in EEPROM or FLASH memory on the card (mostly 20 – 200 kB). ∙ Random generator – a fast source of truly random data. The communication is ensured by contact or contact-less interface (can be combined). Data processing is ensured by operating system of a smart card. MultOS and JavaCard are currently two operating systems notable on the market. This thesis focuses on JavaCard platform.

1. Expression "JavaCard" claims to a software platform, by "Java card" we mean physical hardware device. 2 2. JavaCard platform 2.2 JavaCard Specifications

JavaCard refers to a software technology that allows Java-based applications (applets) to be run on smart cards. It provides cross-platform and cross-vendor applet interoperability. The first Java card was introduced in 1996 by Schlumberger’s card division [4]. The JavaCard Platform specifications were developed by Sun Microsystems, nowadays maintained by Oracle [5]. From version 3.0 it consists of two editions: Classic and Connected. We focused only on the Classic Edi- tion. The JavaCard Runtime Environment (RE) is significantly limited version of full Java RE, including two parts:

∙ The JavaCard Virtual Machine (JCVM) - an isolated environment where applications are being executed separately from the underlying operating system and hardware.

∙ The JavaCard API - the core framework which allows to extend Java packages and classes for smart-card applications.

2.2.1 JavaCard limitations JavaCard should be capable of running Java applications. Unfortu- nately, there are significant limitations, mainly due to smart card hardware restrictions and missing standard library packages what requires changes during applet development. Developer cannot use standard Java functionalities such as threads, dynamic class loading, object cloning or annotations. Security Man- ager (java.lang.SecurityManager) from standard Java platform is also unavailable. Supported primitive types are boolean, byte, short, int (optional). There are no char, double, f loat or long types, nor multidi- mensional arrays. JavaCard contains Exception handling and simple Garbage collection (implementation is manufacturers choice). JCVM restricts a maximal number of class implemented interfaces (15) or class implemented methods (128). Since smart cards depend on a power supply, the memory management also requires a different attitude of usage. We have mentioned only main restrictions. The full list is available in the JCVM Specification [6].

3 2. JavaCard platform

2.2.2 Applet development and communication Most JavaCard implementations rely on GlobalPlatform [7] which handles the applet management on a smart card. It is implemented by a card manufacturer during production. Asynchronous communication between the card and a reader is built upon the Application protocol data unit (APDU). Data transfer is always initiated by the reader (command APDU), the card only answers (response APDU) [8]. When we want to run an applet on a smart card, subsequent necessary steps have to be completed. 1. Class Javacard. f ramework.Applet is extended. Methods install, register, select and process should be implemented. 2. A source code (.class) is converted to a byte-code using standard Java compiler. 3. The byte-code is checked and converted to an applet (.cap) by Java-Card converter. 4. The applet is uploaded and installed into a smart card. The applet is inactive after the installation. Communication with the applet is being carried out accordingly to the following steps. 5. The SELECT command is sent and handled by Card Manager. It sets the applet active, and calls select method. 6. Our applet receives APDU command and calls process method which processes received data and sends an outgoing response. 7. The applet is waiting for another command (as in step 6). 8. Deselection of the applet may be performed by the DESELECT command. Then, the applet is set inactive.

2.3 Cryptography provided by JavaCard

The primary purpose of smart cards is to provide security. Confi- dentiality, data integrity, authentication and non-repudiation may be ensured with smart cards. The JavaCard API provides specification of all frequently used cryptographic algorithms (see 4.2.1). Java cards can be used as a secure carrier, they can encrypt and sign data or work as a secure computational device. All in physically tamper-proof body.

4 2. JavaCard platform

2.3.1 Random data Smart cards provide True Random Number Generator. It is usually used as a source of randomness for cryptographic algorithms. Smart cards may use several techniques such as direct amplification of a noise source, jittered oscillator sampling or discrete-time chaotic maps [9] to generate truly random data. JavaCard provides two random generator functions, ALG_SECURE_RANDOM and ALG_PSEUDO_RAN- DOM (usually equal to ALG_SECURE_RANDOM).

2.3.2 Hash functions JavaCard supports several hashing algorithms in class MessageDigest. There are available: vulnerable MD5, deprecated SHA-1, RIPE MD- 160 and SHA-224 – SHA-512. SHA-3 is supported by JavaCard from version 3.0.5. Signature class contains Message authentication code (MAC) available in numerous modes of usage.

2.3.3 Symmetric cryptography Availability of block ciphers on JavaCard is well covered in package javacard.security. Prior usage, Key object has to be initialized and Key value has to be set. Algorithms DES, Triple DES, AES, and Korean SEED are present in the JavaCard API specification. They can be used in common modes (CBC, ECB) and various padding schemes (e.g., ISO 9797, PKCS#5).

2.3.4 Asymmetric cryptography From asymmetric algorithms are available: Diffie-Hellman, RSA, DSA and Elliptic curve (EC) implementations. We can perform session key exchanges, create signatures or encrypt data. RSA is supported in classic and Chinese Remainder Theorem (CRT) mode, with modulus size up to 4096-bit. JavaCard allows using RSA algorithm in combination with SHA and RIPEMD hash functions for digital signatures.

Please note, that even though the JavaCard API contains specification of a cryptographic algorithm, a particular card may not implement it at all. More about this issue is discussed in Chapter 4.

5 3 Measuring the performance of JavaCard

The main characteristic of smart cards is strong security which en- tails specific limitations that make performance testing more difficult. Standard edition of Java Platform contains ClassSystem [10] providing methods (currentTimeMillis(), nanoTime()) to measure elapsed time and to easily calculate execution time (hereinafter referred to as run time) of chosen operation. Unfortunately, the situation with JavaCard is different. The selected action cannot be measured directly since there is no on-card timer implemented, moreover due to protected environment of JavaCard. That is the reason why we are not able to estimate the time of operation inside the Java card. De facto, we are in the same position as a potential card attacker, we are unable to manipulate the JavaCard secure environment, we cannot see protected memory and storage directly. We are only capable of measuring a response time of a smart card using the timer on a host computer (PC). However, the response time does not include just run time of operation. It also contains overhead that we do not want to be part of results. This overhead appears because there exists a significant and non-predictable elapse of time between the beginning of the measurement (start of the timer on the host PC) and the actual execution of the code of interest. When performing a request, the execution call has to travel several software and hardware layers down to the card and back up through JavaCard’s Virtual Machine to the host PC. Still, the performance of these devices can be measured and as- sessed with a proper benchmark. In computing, a benchmark is an act of running specific tests to evaluate the relative performance of an object, in our case, JavaCard operation. Benchmarking of JavaCard platform requires some subtle attitude to obtain execution results that reflect the actual isolated execution time of the feature of interest as accurately as possible.

3.1 Performance testing

Performance testing is a non-functional testing technique, performed to determine the JavaCard’s performance parameters. This process

6 3. Measuring the performance of JavaCard

may involve quantitative tests, especially measurement of response time and also includes qualitative attributes such as reliability or scalability. However, concerning JavaCard measurement, not all testing techniques are feasible to perform because Java cards are intentionally created as black-box devices.

In this thesis we focus on following two testing practices:

∙ Performance test – This expression in terms of JavaCard testing refers to measuring precise run time of a particular method. The method could be dependent or independent on the length of data. Results are presented in milliseconds.

∙ Scalability test – Term is connected with the previous type of testing. It examines dependency between the length of input data and the run time of the operation.

3.2 Purpose of measurement

The main aim of the benchmark development is to create a compre- hensive database of performance results. Specifically, to measure the time necessary to execute separate methods and subsequently perform analysis based on obtained results. List of tested attributes is discussed in the Section 4.2.1. Despite the fact that the card manufacturer declares support of particular JavaCard version (e.g., JC 3.0.4), not all algorithms are actually implemented. Higher level information (e.g., RSA-2048 support) is usually listed but without detailed documentation (e.g., supported padding methods or signature modes). While this data can be obtained by creating an instance of an object, method is not fully reliable because created instance could fail in usage. Performance testing, therefore, provides real verification of algorithm implementation. In general, knowledge of an exact run time of particular method might help during applet designing and development. Thanks to revealed information two use-cases occur:

∙ Card purchasing – If usage of a particular cryptographic algorithm is required, a card buyer may find and compare two or

7 3. Measuring the performance of JavaCard

more smart cards. Then pick the ideal one that will suit the actual needs.

∙ Card ownership – In case the card is already purchased, supported algorithms can be listed and a suitable cryptographic algorithm can be chosen.

Collected results provide clues to better understanding the performance behaviour of Java cards. They also help to reveal the internal (not public) processes on the card. A good example is non- deterministic RSA key generation which consists of several operations including primality testing. If a lot of keys is generated, we are able to calculate an average number of repetitions of primality testing performed during RSA key generation process [11].

3.3 Related Work

Currently, there is no recent open source solution (except JCAlgTest) to evaluate the performance of a smart card using JavaCard platform. In fact, the programs which realize this type of evaluations are generally proprietary and not made available to the whole JavaCard community. They are designed for developers within a company only. Hence, only a few published benchmarks and publications are available thanks to research laboratories. This thesis extends JavaCard algorithm tester project (JCAlgTest) developed under Centre for Research on Cryptography and Secu- rity (CRoCS) at Masaryk University. Petr Švenda, main advisor of the project, created program AlgTestSuite 1.0 (Java Card’s algorithms support test). This tool is elaborated in Chapter 4. In 2008, Karol Kubanda extended AlgTestSuite 1.0 and created initial performance testing tool (applet AlgSpeedTest and host application AlgTestPC), as a part of his Bachelor’s thesis [12]. He tested 5 smart cards and compared results with the performance of a standard computer. In 2014, Lenka Kuníková continued in performance benchmark development and created three separate programs (speedTest, speedTestPC and postProcessing) in her Bachelor’s thesis [13]. She implemented a more efficient way of testing and made the tool fully automated. Her

8 3. Measuring the performance of JavaCard

results, from 7 tested cards, consists of basic HTML pages, including graphs. A few teams outside Masaryk University also tried to measure JavaCard performance. One of the biggest open source projects was MESURE project [14] founded by the French government. They started in 2006 and created complex benchmark framework. However, a pub- lication with certain run times for an individual Java cards is not available. Results are provided only on global base as a "global performance mark" computed for each card. Unfortunately, the project is no longer active and it appears to be terminated. Following publications provide less extensive (but detailed) analysis of selected cryptographic methods. First, from Cryptology Research Group of Brno University of Technology, they benchmarked and compared base cryptographic primitives over three smart cards platforms (JavaCard, .NET and MultOS - 5 cards in total) and three Android devices [15]. The study of RSA Performance in Java Cards estimates possibility and predicts the operation time of RSA-4096 functions on smart cards, nowadays supported exceptionally [16].

3.4 Measuring the execution time - Power analysis

Smart cards, as electrical devices, fluctuate in power consumption, what occurs as different operations are performed. Power analysis involves examination of power traces (graphs) of electrical activity over time. These graphs are provided by an oscilloscope which is connected to the circuit between the smart card and a host computer. The oscilloscope samples currently used power. This kind of analysis is considered as a form of side channel attack in which an attacker studies the power consumption of a smart card. In some cases the attacker may non-invasively extract cryptographic keys and other secret information from the device [17]. Power analysis is very accurate and provides additional information but requires a lot of effort, cannot be fully automated and initial costs (mainly for the oscilloscope) are significantly higher compared to the method described in Section 3.5. In our case, we are not performing power analysis in order to extract secret information from JavaCard. We are analysing power trace to find exact points where the operation starts and where it ends. Then

9 3. Measuring the performance of JavaCard

Figure 3.1: Annotated example of power trace of the RSA key pair generation (genKeyPair()). The beginning and the end of generation are clearly recognizable. Also, optional RSA decryption (depend on the card) was successfully identified because bounded part of power trace corresponds to the power trace of standard RSA decryption.

we can calculate precise run time of operation by simple subtracting start time from end time. However, not all operations can be measured that way. Card manufacturer may use masking, such as performing random operations (we filter them through repeated measurements), in order to add noise to the power trace, therefore, it can be difficult to identify the start and the end point of method correctly. Power analysis may provide valuable information about implementation of particular method. Nonetheless, it is not always practicable due to power analysis protection (e.g masking) or inability to observe the fluctuation in power trace. A good example is RSA key generation which consists of several operations (key generation, primality testing, decryption test) [18]. See Figure 3.1 for details.

10 3. Measuring the performance of JavaCard 3.5 Measuring the execution time - Averaging results

This measurement methodology is used to isolate run time of selected operations running on Java card, even if no timer is provided by JavaC- ard platform. No special devices are required, just host PC, card reader and a smart card. The measurement is performed by the host PC and consists of two parts. The first one measures the time to execute the “empty loop”. The empty loop contains all measured operations and the whole communication except the line of code corresponding to the operation, we want to evaluate. The second part consists of measurement of the “full loop” execution. The full loop consists of the same code, but also contains the line of code corresponding to the operation, we want to measure. Finally by subtracting the time of “empty loop” from the “full loop” time, the difference we obtain should be equal tothe execution time of omitted operation and does not include the overhead. The overhead is non-predictable, primary affected by performance variations among tested cards, together with different software and hardware characteristics of the benchmark environment such as card reader, host PC configuration, the OS level interferences or the PC’s Virtual Machine. Another complication rests in an inability to test certain methods which depend on previous calls of methods related to them, inde- pendently. In this case, we need to measure the time to execute all necessary methods separately. Then we can call all necessary methods consecutively with the code of interest and afterwards we evaluate the result run time. For example, during RSA key pair generation, a new object has to be created (newKeyPair()) prior to calling the genKeyPair() method that we want to benchmark. Considering expected deviations in measurement, we execute operations multiple times, to increase the accuracy. Selected method was repeated 50 times in a row directly on the card in a single test run. The reason is to be ensured, that the operation run time is sufficiently large to be correctly measured. As a precaution, the whole test is launched 5 times. Process is visually described in Figure 3.2 in detail. Full automation and low hardware requirements are major benefits of described technique. That is why it is implemented in JCAlgTest (more in Chapter 4).

11 3. Measuring the performance of JavaCard

∑n Operation time − ∑n Calibration time Average time = i=1 i i=1 i n (3.1) where n = number of repetitions

Figure 3.2: Listed segments show all parts of performance test execution [19]. Part 5 executes target operation we want to measure (green). Since we are not able to perform this execution directly, by subtracting the time of execution of all operations in the left column from all operations in the right column, we gain quite an accurate operation run time. The subtracted time consists of host PC processing (yellow), data transmission between host PC and a card (yellow-blue) and smart card processing (blue). To increase the accuracy of results, the whole testing is repeated several (in default 5) times. The final result is computed using Formula 3.1.

12 4 JCAlgTest

What kind of a smart card? What version of JavaCard API? How much RAM and persistent memory? Which algorithms are supported by the card? How long does it take to execute selected algorithm?

It may seem to be problematic to answer those questions. The solution is Java Card Algorithm Tester (JCAlgTest), tool which measures, assesses and provides answers to all of them. The JCAlgTest is a tool designed for automatic gathering various properties of smart cards. It focuses on JavaCard platform with corresponding JavaCard API specification (from 2.1.2, from 3.0 classic edition only). Testing requires only to upload an applet to the target smart card and launch a host PC application with desired test command. Afterwards, the tool provides obtained information. From basic like RAM size to high-level such as algorithm support or method execution time. These are introduced in Sections 4.2 and a 4.3 in detail.

JCAlgTest consists of 3 main parts (packages):

∙ JCAlgTest – Applet which is uploaded to tested Java card and communicates with host PC. Contains two main parts.

– Algorithm support - checks whether the tested Java card supports particular cryptographic algorithm or not. – Performance testing - benchmarks specific card and provides run times of cryptographic algorithms in various modes and variable data lengths.

∙ JCAlgTestClient – Application, running on a host PC that en- sures communication with the card. Manages whole testing and stores greathearted information.

∙ JCAlgTestProcess – Generates tabular and graphical outputs based on test results. They all are available on the project website. [20].

13 4. JCAlgTest 4.1 Project overview

4.1.1 History

The JCAlgTest project has been developed under the CRoCS laboratory at Masaryk University, started by Petr Švenda in 2008. As a main advisor of project, he created program AlgTestSuite 1.0. In the beginning, it covered just algorithm support testing. Next year the database contained results from 12 tested cards. Besides Petr Švenda, there were another project developers. Karol Kubanda created the first performance testing implementation, as part of his Bachelor’s thesis [12]. Lenka Kunikova improved this implementation, also, as a part of her Bachelor’s thesis [13]. Performance testing, as a part of JCAlgTest, was released in September 2015 with first results. Client application was initially written in C++ language. Later rewritten to Java for better portability and usability. Java language contains API for communication with smart cards using ISO/IEC 7816- 4 APDUs (package javax.smartcardio), so no additional libraries are required. Mentioned API is a part of JDK from version 6, independent from proprietary libraries. This change has facilitated testing, caused easier usage of the tool and brought results provided by the volunteers worldwide. Post processing application was also programmed in Java. From April 2013 project is being active on GitHub, communicating with the community, resolving issues and accepting pull requests from another four contributors [21].

4.1.2 Current state and plans

In May 2016, project database contained support information from 51 smart cards and detailed performance results of a third of them. CRoCS laboratory provide 28 different tested smart cards. The rest is provided by the volunteers worldwide. Results are available on project website [20], all for free. Examples of individual outputs are shown and discussed in the Performance analysis in Chapter 5. Project was presented at the 17th International Workshop on Anal- ysis of Security API, ASA’14, Vienna, A satellite workshop of CSF 2014 [22]. Performance results were used during analysis and prototype

14 4. JCAlgTest

implementation of hardware security architecture. Work is described in paper Architecture Considerations for Massively Parallel Hardware Security Platform presented at SPACE 2015 [23]. A server with on-line service is being planned in future. Any card holder can upload their test results. In response he will receive information about the smart card. Service shall include automatic smart card recognition and fingerprinting.

4.2 Algorithm support – JCSupport

Cryptographic smart cards hold an important role as trusted components. When designing secure system, several necessary cryptographic algorithms are required from the chosen smart card. JavaCard platform itself provides most of the commonly used cryptographic algorithms, but no actual smart card implements entire JavaCard API. Which algorithms will be supported depends on the card manufacturer. Set of natively supported algorithms is defined during card designing and permanently burned into ROM memory in production and cannot be easily extended. The main reason is that cryptographic functions usually need to be hardware-accelerated and run on auxil- iary coprocessor inside a smart card. Algorithms support information are not easily reachable. Card manufacturer does not facilitate the situation. The sales brochure of the card often shows just basic information. For instance JavaCard version, memory size or support of few selected methods. List of all implemented algorithms is provided rarely. The JCAlgTest project helps by providing search for a suitable card with proper support. Since the JavaCard API contains hundreds of methods, a manual testing in a wide range is not a viable option. The tool provides fully automated testing of Java card within a few minutes (2 - 10). The size of the applet which performs testing is only 6 kilobytes so it can be installed on older cards either. It stands on the Exception handling which is supported by JavaCard platform. Tool tries to create an instance of every single algorithm. Whether the creation of an object is successful or not, applet reports the result to the host computer. An example of instance creation in applet code is shown in Listing 4.1.

15 4. JCAlgTest try{ //create instance of an object digest = MessageDigest.getInstance(algorithmClass, false); //store support information apdubuf [(short) (ISO7816.OFFSET_CDATA)] = SUPPORTED; } catch (CryptoException e) { //exception handling apdubuf [(short) (ISO7816.OFFSET_CDATA)] = (byte) (e.getReason()); } Listing 4.1: Instance of the JCSupport Applet code

4.2.1 List of tested properties ∙ Card information Version of JavaCard, Answer To Reset (ATR), Card Production Life Cycle (CPLC)

∙ Size of memory Persistent (MEMORY_TYPE_PERSISTENT), Transient (MEM- ORY_TYPE_TRANSIENT_RESET, MEMORY_TYPE_TRAN- SIENT_ DESELECT)

∙ Classes AESKey, Checksum, Cipher, DESKey, DSAKey, DSAPrivateKey, DSAPublicKey, ECKey, ECPrivateKey, ECPublicKey, HMACKey, KeyPair, KoreanSEEDKey,MessageDigest, RandomData, RSAPri- vateCrtKey, RSAPrivateKey, RSAPublicKey, Signature, Util

∙ Software reimplementation AES, XOR

4.3 Performance testing – JCAlgTest

JCAlgTest also provides measurement of the run time of specific operations. The purpose of the measurement and theoretical view are described in Chapter 3 – Measuring the performance of JavaCard. In this Section we describe information related to JCAlgTest performance testing only. We complete the description with pseudo-code of measurement 4.1 which covers both PC host and a card part of the measurement.

16 4. JCAlgTest

Performance measuring compared to algorithm support testing cannot be run on all Java cards due to memory requirements. Size of the applet which includes performance testing is over 20 kilobytes. That hits the memory limits of older cards. Additional constraint lies in the support of JavaCard platform from version 2.2.1 and later. However, it is not such a relevant problem because the majority of tested cards supports JavaCard 2.2.1.

PC host application Applet process() Applet methods start = getTime() for(5x){ sendTestAPDU() process(){ prepare() prepare(){ new object() } perfTest() perfTest(){ for(50x) { measuredOp() }} } responseAPDU() end = getTime() result = (end-start)/(5*50)

Table 4.1: Simplified pseudo-code of performance measuring

Time of measurement is also significantly different. While support testing takes only several minutes, the performance measurement may take several hours. It depends on algorithm support, card performance and range of testing. Performance testing can run in two modes, both providing execution time in milliseconds for specific amount of processed data.

∙ Data fixed – Wherever possible, it is used 256 bytes data length. ∙ Data depend – In default, 6 data lengths are tested (16, 32, 64, 128, 256, 512 bytes)

17 4. JCAlgTest

Since some operations may require pre-processing (create an object, set a key), tool also measures two variants: ∙ Separate method only – time of execution of individual method (e.g., doFinal()) ∙ Whole cryptographic operation – contains all necessary calls to perform whole operation (init(), setKey(), doFinal())

//manage test preparation and execution public void process(APDU apdu) throws ISOException { byte[] apduBuffer = apdu.getBuffer(); if (apduBuffer[ISO7816.OFFSET_CLA] == KEYPAIR) { prepare_KeyPair(apdu); perftest_KeyPair(apdu); } else ISOException.throwIt(SW_ALG_OPS_NOT_SUPPORTED); }

//prepare object to KeyPair generation- part of overhead void prepare_KeyPair(APDU apdu) { //setting properties of specific test byte[] apdubuf = apdu.getBuffer(); settings.parse(apdu); try{ //prepare object keyPair = new KeyPair((byte) settings.keyClass, settings.length);

//send information about successful preparation apdubuf [(short) (ISO7816.OFFSET_CDATA)] = SUCCESS; apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, (byte) 1); } catch(CryptoException e) { //algorithm not supported, exception handling(not shown) } }

//method that contains measuring of KeyPair generation void perftest_KeyPair(APDU apdu) { byte[] apdubuf = apdu.getBuffer(); settings.parse(apdu);//settings of specific test try{ //run operation several time for greater accuracy for(short i = 0; i < settings.numRepeatOp; i++) keyPair.genKeyPair();//measured operation

//send information about successful measurement apdubuf[ISO7816.OFFSET_CDATA] = SUCCESS; apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, (byte) 1); } catch(CryptoException e) { //exception handling(not shown in the example) } } Listing 4.2: Applet source code example of JCAlgTest performance measuring (modified for presentation purposes). Individual test consists of two parts, preparation and measurement.

18 5 Performance analysis

The primary goal of this thesis is presented in the this chapter. Work has been done mainly on JCAlgTestProcess, part of JCAlgTest. The initial implementation (the Support table) has been updated for better presentation of measured results. New functionality for card comparison and results presentation was added. As shown in Figure 5.1 JCAlgTestProcess gets raw data from measurement as Comma-separated values (CSV) format, processes it and provides various types of output files. Measured performance data are used as a basis for demonstration of selected outputs together with a discussion about the performance of Java cards. Complete results, in all forms, were published on new JCAlgTest website [20].

Figure 5.1: Data flow of JCAlgTest tool.

19 5. Performance analysis 5.1 List of measured Java cards

CRoCS laboratory provided the majority of cards tested for performance. Testing was performed on a regular notebook. Card reader Gemalto IDBridge CT30 (Gemplus USB Smart Card Reader) was used for the most measurements. 20 cards from 7 manufacturers are listed below.

Manufacturer Card name JC version Feitian JavaCOS A22 CR-ECC-SHA-2 3.0.4 JavaCOS A22 3.0 JavaCOS A40 3.0 G+D SmartCafe Expert 6.0 80K 3.0 SmartCafe Expert 3.2 72K 2.2.1 SmartCafe Expert 4.x V2 2.2.1 Gemplus GXP R4 72K 2.2.1 Infineon CJTOP 80K SLJ 52GLA080AL M8.4 2.2.2 NXP JCOP 21 V2.2 36K 2.2.1 JCOP 21 V2.4.2 R3 3.0 JCOP 31 V2.2 36K 2.2.1 JCOP 31 V2.4.1 72K 2.2.2 JCOP 41 V2.2.1 72K 2.2.1 JCOP J2A080 80K 2.2.2 JCOP J2A081 2.2.2 JCOP J2D081 3.0 JCOP J3A080 V2.4.1 2.2.1 JCOP J3A081 2.2.2 Oberthur ID-ONE Cosmo 64 RSA v5.4 2.2.1 Softlock SLCOS Infineon SLE 78 3.0.4

Table 5.1: List of performance tested Java Cards

20 5. Performance analysis 5.2 Development

We used following tools to produce all outputs presented in this thesis.

∙ GlobalPlatformPro - Allows to load and manage applets on JavaCard smart cards which comply GlobalPlatform specification. Easy to use, multi-platform, free and Open Source. [24]

∙ NetBeans IDE - Provides various developer tools and support multiple languages. All parts of JCAlgTest were programmed using it. [25]

∙ HTML, CSS, JS - Results are produced as HTML pages. We care about responsiveness and usability. Pages were styled using Cascading Style Sheets (CSS). JavaScript was used as a part of Bootstrap Framework, D3.js library [26] (Radar graphs) and Google Charts.

∙ Google Charts - Provide free API to present results in an interactive form. Rich gallery or charts and extensive set of options for customization are available. [27]

∙ Bootstrap - Popular open-source HTML, CSS, and JS framework for developing responsive projects on the web. [28]

5.3 Run time information tables

Even though CSV files contain all information from performance measurements, additional processing was used to provide clearer and better-structured text output in tabular form. HTML page is generated from CSV file for each card. Test details (e.g., date, JCAlgTest version), JavaCard version, available memory and CPLC information are located at the beginning. We selected 25 frequently used functions and marked them as TOP FUNCTIONS. We are using them also in other types of outputs. They can be easily changed or extended in future. Table based on TOP FUNCTIONS is a part of HTML page. An example of this table is shown in Figure 5.2. Each row of the table contains the name of measured function, time of execution (average, minimum, maximum),

21 5. Performance analysis data length and minor information such as preparation time (average, minimum, maximum) and a number of test runs. If there is an unsupported algorithm or specific value returned by card, information is written in the row. Rest of the page consists of 20 tables presenting each group of tested methods. They are designed in the same style as TOP FUNCTIONS table.

5.3.1 Number of executed tests

JCAlgTest in data-fixed mode obtains over 2300 test records per one card. Since algorithms are tested in different operation and padding modes on various key lengths, cards generally support only part of them. Most of supported combinations (570) are from G+D SmartCafe Expert 3.2 72K. Least (261) came from three NXP cards: JCOP 21 V2.2 36K, JCOP 31 V2.2 36K, and JCOP 41 V2.2.1. These values do not represent algorithm support exactly. We are just demonstrating ratio between all possible and real gathered results.

Figure 5.2: Part of TOP FUNCTIONS table which provides performance overview of 25 frequently used functions.

22 5. Performance analysis 5.4 Comparative table

Simple Java card comparison is provided by the Comparative table. It allows sorting cards accordingly to performance results for a particular algorithm. Each row represents tested card and column represents specific method. Cards can be sorted just by click on a name ofthe algorithm in the table header. Available is ascending and descending sorting. Unsupported algorithms are supplied by "-" symbol and they are placed at the end of ascending sort. While hovering the cursor over any run time, minimum and maximum run times are displayed. We generate the comparative table for TOP FUNCTIONS only to preserve clarity of results. In fact, we are producing two tables, first for symmetric and second for asymmetric cryptography algorithms. Set of TOP FUNCTIONS can be changed or extended to generate a different comparative table.

Figure 5.3: The comparative table allows sorting cards based on their performance for individual algorithm. Cards are sorted according to the speed of the Secure random data generation, in shown example.

23 5. Performance analysis 5.5 Overall performance visualisation

The comparative table offers an opportunity to review cards performance from a particular algorithm perspective. We created a solution which provides a review of a card in overall. It is implemented using the visual data presentation. Radar graphs allow displaying multivariate data in the form of a two-dimensional chart. We applied TOP FUNCTIONS data on axes of radar graph. The performance of a particular algorithm is demon- strated as a distance from the centre of the chart. Faster the card is, the longer is the distance. We compared run times of an algorithm across all cards and assigned values from interval 0.1 – 1.0 to each one. If the card does not support particular algorithm, we assigned value 0.0. Then are values placed on the graph and connected to create a circuit. Graphs are not static, after hovering pointer above some point, the actual execution time of algorithm will be displayed.

SECURE RANDOM (256B) SECURE RANDOM (256B) SHA1 hash (256B) 100% RSA2048 generate SHA1 hash (256B) 100% RSA2048 generate

SHA2256 hash (256B) 90% RSA1024 generate SHA2256 hash (256B) 90% RSA1024 generate

80% 80%

3DES encrypt (256B) RSA2048 encrypt 3DES encrypt (256B) RSA2048 encrypt 70% 70%

60% 60%

AES128 encrypt (256B) RSA2048 decrypt AES128 encrypt (256B) 50% RSA2048 decrypt 50%

40% 40%

30% 30% AES256 encrypt (256B) RSA1024 encrypt AES256 encrypt (256B) RSA1024 encrypt 20% 20%

10% 10%

3DES setKey(192b) RSA1024 decry3pDtES setKey(192b) RSA1024 decrypt

AES setKey(128b) RSA2048 CRT generateAES setKey(128b) RSA2048 CRT generate

AES setKey(256b) RSA1024 CRT generate AES setKey(256b) RSA1024 CRT generate

SWAES oneblock (16B) RSA2048 CRT encrypt SWAES oneblock (16B) RSA2048 CRT encrypt

arrayCopy nonAtomic RAM2RAM (256B) RSA2048 CRT decrypt arrayCopy nonAtomic RAM2RAM (256B) RSA2048 CRT decrypt

arrayCopy nonAtomic EEPROM2EEPROM (256B) RSA1024 CRT encrypt RSA1024 CRT decrypt arrayCopy nonAtomic EEPROM2EEPROM (256B) RSA1024 CRT encrypt RSA1024 CRT decrypt Figure 5.4: Radar graphs provide visual performance comparison. Example shows the best and the worst performance result. On the left side Feitian JavaCOS A40, on the right side Oberthur ID-ONE Cosmo 64 RSA v5.4.

5.5.1 Overall performance comparison We used calculated data from Radar graphs and tried to sort tested cards according to the performance. However, to calculate the accurate

24 5. Performance analysis

rating of a card which would be presented by one value only is not a trivial task. The diversity of supported algorithms must be also taken into account. The intersection of supported algorithms by every card is small. So the cards are practically not directly comparable, in an overall mark. That is why we are not attempting to build a benchmark which will assign a particular amount of points to each card. We only calculate performance order of 20 tested cards. Procedure:

1. Run times were normalised to values 0–1 for each function. (value 1 holds the slowest card, values close to 0 represent fastest cards).

2. All normalized values were averaged for each card.

3. The resulting values were inverted and they are shown in Figure 5.5 in percentage.

Overall card performance comparison 100% 88% 87% 90% 84% 81% 78% 80% 76% 74% 71% 70% 68% 70% 66% 65% 65% 64% 62% 59% 57% 60% 51% 50% 46% 40% 30% 18% 20% 10% 0%

Figure 5.5: Comparison overall performance of Java cards. Values are defined by the particular set of tested cards. Higher percentage means better overall performance. The fastest are JavaCOS cards from Feitian. Oberthur ID-ONE Cosmo 64 RSA v5.4 is the slowest from all measured cards.

25 5. Performance analysis 5.6 Data length dependency graph

Every card manufacturer may implement the particular algorithm in a different way. He can use special co-processors, various internal caches or security precautions. Since these implementations are not revealed, we do not know what we can expect regarding dependency between data length and execution time. Data dependency graphs can be used to reveal the time required to complete operation relying on data length. It is build upon a candle chart. In default, 6 data lengths (16, 32, 64, 128, 256, 512 bytes) are tested. As run time tests are performed several times, graphs are also showing minimal and maximal time of execution. In terms of scalability, the majority of results contains fixed overhead (the start and the end of operation), rest of the time linearly depends on data length. We can observe also other relations. As shown in Figure 5.6, first 128 bytes behave linearly with respect to processed data length with a significant non-linear increase between 128 and 256. It is probably caused by the length limit of internal memory used by the co-processor. Knowledge of this behaviour may help the developer to optimise the code by processing smaller chunks of data.

5.7 Performance similarity table

We focused on the Java cards performance for particular algorithms, in previously presented outputs. This section deals with the performance similarity of cards. We calculated how much individual pairs of cards differed in the performance. We normalised set of TOP FUNCTIONS to values 0–1 for each algorithm. Then we picked mutually supported algorithms for each pair of cards and using modified Euclidean distance formula 5.1, we calculated the difference in similarity.

p = (p1, p2, ..., pn), q = (q1, q2, ..., qn) r ∑n (p − q )2 d(p, q) = i=1 i i (5.1) n

p, q are sets of mutually supported algorithms by cardp and cardq

26 5. Performance analysis

NXP J3A080 TYPE_DES LENGTH_DES3_3KEY ALG_DES_ECB_ISO9797_M1 Cipher_doFinal()

500

512

) 375 s m (

n o i t

a 256 r

e Time (ms): 206,64 [206,2, 207] p 250 o

256 f o

n o i t a r u

d 125

16 32 64 128 0 0 100 200 300 400 500

length of data (bytes) Figure 5.6: Scalability graphs provide insight into the performance of card depending on the length of input data. Graphs are interactive on web presentation. While hovering a cursor above point, a tooltip with run time values is displayed.

Obtained values were inverted (abs(result − 1)). They are shown in percentage in Figure 5.3. Names of cards are placed in a top row and left column of the table. Each value in the table represents similarity of two cards. Values close to 100% express that cards are very similar, close to 0% mean performance difference. When a cursor is placed above value, tooltip showing difference in supported algorithms of exact two cards appears. Result table contains several groups of similar cards. The biggest observed group is among all NXP Java cards. Minimal difference is between NXP JCOP 21 and NXP JCOP 31, NXP J2A080 and NXP J3A080. This is expected as closer inspection of datasheet reveals that given cards are just variants of the same underlying hardware platform. Same for JavaCOS A22 and JavaCOS A40, chip Infineon SLE78 is used inside both. Contrary, Oberthur ID-ONE Cosmo 64 RSA v5.4 is very different from all the other tested cards. In general, we can say that pair of cards which has similarity value over 95% is identical or contains the same chip. Similarity of 85% –

27 5. Performance analysis

95% usually signals same family of cards. The global average was 70.27%, therefore values in this area indicates no connection. Under 50% means that cards are totally different in performance. This technique may be used for identification of broken card from a batch of supposedly identical cards.

5.8 Conclusions and recommendations

We provided several options how the Java cards can be compared, from overall, single card and single algorithm perspective. In the end, we add recommendation which card to choose for a particular type of usage (purely from the performance, not the security view) from our set of tested cards.

∙ Secure random – Gemplus GXP R4 72K (2.45 ms / 256 B)

∙ SHA-1 – Gemplus GXP R4 72K (3.69 ms / 256 B), Feitian JavaCOS A40 (3.96 ms / 256 B)

∙ SHA-2 – NXP JCOP J3A081, NXP JCOP J2D081, NXP JCOP JCOP 21 V2.4.2 R3, NXP JCOP J2A081 (21.05 ms / 256 B)

∙ AES – Softlock SLCOS InfineonSLE78 (2.48 ms / 256 B encrypt)

∙ RSA-1024 – Feitian JavaCOS A40 (3.38 ms / CRT encrypt, 25.04 ms / CRT decrypt)

∙ RSA-2048 – Softlock SLCOS InfineonSLE78 (7.94 ms / CRT encrypt, 139.55 ms / CRT decrypt)

When buying Java card, check whether required algorithms are supported. Prefer newer version of JavaCard and bigger RAM and EEPROM size. From the security point of view choose a card which has some form of certification (e.g., CC EAL5+ or FIPS-140 level 3).

28 5. Performance analysis n 8 S o 1 5 0 1 5 5 2 3 6 4 8 5 6 6 1 6 2 9 6 7 O

e 5 3 3 6 6 3 3 2 3 9 7 7 5 6 6 4 9 7 5 ...... E C n 5 3 5 9 5 1 6 8 2 1 1 7 3 0 1 6 6 1 9 i L L f 5 7 6 4 6 8 8 8 8 7 7 6 6 7 8 7 7 8 2 n S S I o E A 6 1 0 0 4 1 2 4 0 4 5 1 9 5 9 9 8 7 6 4 S N m 3 3 6 3 4 8 6 5 5 3 3 9 6 1 3 0 6 4 5 ...... R s 5 O

6 1 4 1 5 1 8 2 7 5 2 6 2 4 3 5 3 7 9 o v 4 4 4 3 4 3 3 2 1 3 4 4 4 4 4 4 4 4 3 2 D C I 6 1 9 1 3 8 3 8 6 4 1 2 6 6 5 0 3 9 7 9 P 1 8 1 3 9 7 4 3 3 0 6 9 5 8 1 8 2 0 1 4 7 0 O ...... A 0 1 2 8 0 9 5 3 6 0 0 8 5 6 1 8 0 7 1 C 2 8 6 8 6 6 6 8 8 8 9 8 7 7 6 8 8 8 3 8 J J 5 7 1 8 5 2 4 3 3 8 9 6 7 9 5 5 9 8 2 P 2 K . 2 6 5 1 1 8 7 6 3 5 7 3 1 3 3 1 1 6 9 1 O ...... 6 2 3 5 0 2 1 5 0 7 1 4 4 8 5 0 0 0 7 0 3 6 C 3 V 6 8 6 6 6 7 6 8 8 8 8 8 9 8 9 9 8 4 7 J 0 5 4 1 8 8 5 7 9 3 3 9 3 6 2 5 9 6 P 1 2 K . 1 3 4 7 2 1 8 0 3 7 7 8 5 4 9 2 1 0 4 1 O ...... 6 2 2 0 6 0 2 1 5 0 7 9 3 5 9 6 0 0 0 7 5 6 C 3 V 8 6 8 6 6 6 7 6 7 8 8 8 8 9 8 9 9 4 7 J 1 7 4 7 4 3 3 0 7 7 2 6 4 3 2 2 5 3 9 1 P . K 6 5 0 8 4 7 3 8 6 0 1 5 3 1 2 3 0 3 6 2 1 O ...... 2 4 7 7 7 3 9 0 5 1 0 1 9 9 3 8 0 0 8 3 1 2 C 7 6 8 6 6 6 8 7 8 9 9 8 8 8 8 9 9 8 4 8 J V 1 4 8 2 0 5 4 5 4 3 3 8 7 2 2 6 9 0 5 6 P . K 2 2 4 6 8 3 3 4 1 0 2 4 8 1 9 3 2 1 6 4 1 O ...... 2 3 3 2 1 8 4 0 6 7 9 0 1 7 4 8 0 0 1 4 0 2 C 7 7 8 7 6 7 7 6 7 7 9 7 8 6 8 8 8 8 4 7 J V 2 0 3 5 7 1 3 4 7 2 0 0 4 2 3 3 7 5 9 6 P . 3 3 0 7 5 4 5 8 0 7 6 5 8 3 4 1 8 6 5 3 4 1 O ...... 2 R 4 1 1 9 9 5 5 1 5 3 6 3 4 3 0 0 6 2 3 2 C 6 7 6 5 5 5 5 7 7 7 8 7 6 8 9 9 6 4 6 J V 0 1 5 5 8 6 5 4 3 7 4 2 8 4 7 4 9 6 6 1 5 P 8 . 4 5 8 1 0 3 9 8 7 8 3 5 4 5 5 3 1 9 7 0 4 O ...... A 7 0 9 8 2 2 8 5 7 3 5 3 7 9 6 5 5 6 7 2 C 3 7 8 6 6 7 6 5 7 7 9 7 7 8 8 8 8 7 4 6 J V J 1 3 2 5 1 6 8 0 6 5 9 8 0 8 6 3 9 6 5 8 P 8 6 0 8 5 2 6 5 7 9 7 3 6 2 1 8 7 8 3 7 0 O ...... D 5 7 3 0 2 9 6 1 5 8 5 6 1 9 9 8 8 2 1 C 2 6 7 6 6 6 6 6 7 8 7 7 8 7 8 8 8 7 4 7 J J 0 5 4 8 3 6 5 4 4 7 9 2 0 3 2 3 8 2 4 4 P 8 K 4 7 4 0 3 6 5 9 4 7 8 7 0 0 7 5 5 3 9 0 O ...... 0 A 5 3 0 8 2 8 4 6 2 8 3 3 0 1 5 4 0 5 1 C 8 2 7 8 7 6 7 6 6 7 8 7 9 7 9 9 8 8 8 4 7 J J 1 1 9 2 8 8 1 6 5 7 5 4 2 3 7 9 3 1 0 6 P 8 8 7 9 4 1 6 7 1 4 9 7 0 1 6 7 3 9 5 3 0 O ...... A 2 3 7 0 8 8 7 9 2 5 7 5 9 0 3 4 0 7 2 C 3 6 8 6 6 6 7 7 8 8 8 7 7 7 9 8 8 9 3 8 J J s o 4 2 3 0 6 5 4 5 4 6 7 7 4 7 7 3 4 4 3 0 C 7 6 3 4 2 6 2 1 9 7 8 8 4 8 3 6 6 5 2 ...... 4 a 9 0 1 4 0 7 7 9 6 1 5 1 7 1 9 1 6 2 8 A v 5 8 8 6 8 8 9 8 7 7 7 7 7 8 7 8 8 1 8 a J S O 5 6 2 2 8 6 4 6 4 0 3 4 5 0 5 4 6 2 2 2 5 7 5 1 4 7 2 7 5 5 9 5 3 3 0 7 0 6 3 C ...... 2 a 8 2 8 7 4 2 7 7 4 6 8 5 6 5 7 7 3 8 6 A v 4 7 5 4 6 9 9 7 6 6 5 5 6 7 6 6 8 2 8 a J C S C 2 O E 0 6 1 0 8 6 5 1 5 8 4 3 4 3 8 2 8 1 5 5 7 3 7 4 7 6 6 6 6 3 4 3 7 8 8 3 8 3 C A ...... R a 4 0 0 9 9 2 7 8 8 9 2 5 0 0 0 0 5 1 1 H C v 5 7 6 5 5 9 8 7 6 6 6 5 7 8 7 7 8 3 8

S a 2 J 2 A L K A 0 0 8 8 3 9 1 8 8 6 8 6 6 5 1 5 3 8 5 3 4 5 8

4 J . 6 3 8 0 4 4 2 1 3 2 0 5 8 4 1 1 3 4 6 0 P ...... L 8 A 3 6 6 6 9 4 0 8 2 2 2 9 4 9 5 5 9 5 5 O S M L 6 7 6 6 5 6 8 6 7 6 7 5 7 6 6 6 6 3 6 T J G 2 C 5 6 4 3 1 0 2 0 8 3 1 6 7 0 4 1 8 8 0 1 P K 4 8 5 0 7 1 4 4 0 5 1 7 6 8 2 1 4 3 6 4 ...... X 2 R 7 3 6 6 9 7 4 0 8 0 8 9 8 3 1 1 0 1 9 7 G 6 6 5 6 5 4 6 6 6 6 6 5 6 6 6 6 6 4 4 e x f . a 4

9 5 3 9 1 2 3 2 8 5 8 5 2 7 4 1 3 0 0 t C 9 1 5 8 3 5 3 9 4 8 8 0 4 0 7 5 7 6 3 2 t r ...... r e V 5 2 6 6 0 8 1 7 0 3 9 1 1 7 2 2 8 4 5 a p 6 6 5 6 6 5 8 6 7 6 6 6 7 6 6 6 6 3 6 x m E S e 0 f . a 6

8 5 4 3 6 6 2 9 4 2 5 3 8 4 5 7 1 1 5 t C K 0 1 8 3 7 7 6 7 7 0 5 3 2 5 4 6 9 3 3 t r ...... 0 r e 3 2 3 6 0 2 0 3 3 7 0 1 2 7 0 0 2 1 3 8 a p 6 6 6 7 7 7 8 8 8 7 8 7 8 8 8 8 8 4 7 x m E S e 2 f . a 3

8 9 6 8 0 5 4 1 5 3 5 0 4 7 0 5 9 6 1 t C K 0 9 4 6 5 5 7 8 4 6 4 3 2 6 3 2 3 3 5 t r ...... 2 r e 3 5 7 3 4 8 9 2 5 5 7 4 3 7 6 5 1 6 5 7 a p 6 6 6 6 5 4 5 6 7 6 7 6 7 6 6 6 6 4 5 x m E S J 8 2 1 1 2 o . . . 7 L K K

2 2 1 0 1 0 1 4 4 2 2 2 L 2 S 0 m 2 0 . . . . . = A r E

2 2 8 8 8 8 8

A 4 4 s 7 8 V K 2 2 2 2 2 a . H 0 0 0 0 0 L

e l K A A 0 2 o i e e e A V V V V V 5 2 0 x S g S 0

A A D A A f f f 8 . . . 7

v C S S

a 8 s m 3 2 2 3 1 1 1 1 1 2 a a a

3 6 4

t i n

4 J J J J 2 3 4 2 3 J O O o C C C E t t t A r S s n o P t t t A

C r r r R 1 C C C e e r r r S

N e . P P P P P P P P P P O L e O e e e E a a a 4 h c a a a 4 r n P R . O T O O O O O O O O O O C p p p . i r G v v v K K K K K g o f 8 X i J R 3 m x m x m x 2 L e 2 a a a C C 0 C C C C 2 C 2 C 6 C 6 C 4 D n H p m S E S E S E G C 5 M J C J J J J 8 J J V J R J 7 J 7 J 3 J 3 J I 6 S I Figure 5.7: Scalability table shows performance similarity between individual pairs of50% cards. (red) Closer are to cards significantly different than average. the 100% (greener) the value is, more similar the pair of cards is. Down to 0% are cards less similar. Under

29 6 RSA key analysis

RSA is public-key cryptosystem, designed by Ron Rivest, Adi Shamir, and Leonard Adleman, who first publicly described the algorithm in 1977. It had been patented till September 2000 when it was released to the public domain. The RSA algorithm is widely used in computer security. Smart cards are no exception. They can ensure encryption, digital signatures and key establishment using RSA cryptosystem [29]. Two sufficiently large prime numbers (p and q) are the base of the algorithm. The modulus n is calculated as p multiplied by q. Security of the RSA algorithm relies on the difficulty to factor the product (n) of two large primes, known as the factoring problem. All newer smart cards allow on-card RSA key pair generation, providing protection of the private key. There are some recommendations how values p and q should look like (e.g., distance between p and q, factors of p − 1 and q − 1) [30]. However, it is the card manufacturer who implements the key generation method (genKeyPair). It is up to him what properties the generated key will have. JCAlgTest provides functionality for gathering and exporting generated values (p and q) for further analysis.

6.1 Factorization of p-1

Factorization of p − 1 values1 is relevant due to potential faulty key generation process. If p − 1 value has only small factors, modulus n can be effectively factored by Pollard’s p - 1 algorithm [31]. As a prevention, some standards like FIPS 186-4 [1] or ANSI X9.31 [2] require usage of primes where the biggest factor of p − 1 has minimal bit length. We can reveal whether a particular card is FIPS or ANSI compliant or not (when generating RSA keys). We collected and factorised 256-bit values taken from 512-bit RSA key pairs. Even though shorter key sizes are insecure to use, they give us the opportunity to factor p − 1 values. We were able to perform factorization in order of seconds because p − 1 values are composed of

1. We have found no difference between p − 1 and q − 1 in factorization results, so p − 1 value always represents both.

30 6. RSA key analysis

Figure 6.1: Histogram generated from 10 000 factorized values of p − 1 and q − 1 taken from 512-bit RSA key pairs. We observed six distinct groups among 14 cards with significantly different distributions in a number of factors. NXP J2D081 and NXP J2E145G have the low- est average number of factors (4.59). Significantly higher number of factors was observed for Infineon CJTOP 80K M8.4 (8.90). Randomly generated primes decreased by one had 7.61 factors on average.

several factors (see Figure 6.1). Factorization of p − 1 values from 1024- bit RSA takes significantly more time, but we also factorised smaller portion of these values for confirmation of obtained attributes. We processed 10 000 p − 1 values from each card using YAFU factorization tool [32]. It implements several algorithms for automatic factorization of integers with support for multi-thread computing 2. Factorised results were compared to randomly generated primes of the same bit length (decreased by 1). We observed following:

∙ Cards varied in an average number of factors of p − 1, details described in Figure 6.1. ∙ A minimal length of the biggest factor of p − 1 (required by FIPS 186-4 and ANSI X9.31) is enforced in Gemalto GCX4 72K (101-bit), Gemalto GXP E64 (112-bit). These cards also have at least 3 factors in p − 1 factorization. Biggest factors were always unique.

2. Acknowledgement: Computational resources were provided by the CESNET LM2015042 and the CERIT Scientific Cloud LM2015085, provided under the pro- gramme "Projects of Large Research, Development, and Innovations Infrastructures"

31 6. RSA key analysis

∙ Cards that remove small factors of p − 1 achieve a smaller average number of factors (and therefore also higher average length of biggest factor). No small factors were present in keys from NXP J2D081, J2E081 (values from 3 to 251 removed) and G&D Smartcafe 4.x, G&D Smartcafe 6.0 (values 3 and 5 removed). ∙ Pollard p-1 factorization method can be used to factorise modulus n if we assume that the number of executed operations is at the most 280. We calculated ranges for 512-bit RSA keys where the factorization is applicable. They vary from 0% (FIPS compliant cards) to 4.35% (Infineon JCOP 80K) with an average of 3.38%. When factoring modulus n, modern factorization algorithms (e.g., NFS, SIQS) are considerably faster in the most of the cases. However, we found a key (from Infineon JCOP 80K, with a small biggest factor of p − 1) which was factorised by the Pollard p-1 factorization method in 19 minutes, whereas the NFS method would take more than 2 000 CPU hours.

6.2 Factorization of p+1

Properties of p + 1 factors are relevant due to Williams p+1 factorization method [33] (analogous to Pollard p-1 method). Same analyses as for prime factors of p-1 were performed. Results of p + 1 factorization for analysed cards were more similar than the result of p − 1 factorization . There is an observable interconnection between a number of factors of p − 1 and p + 1. When p − 1 has fewer factors, then p + 1 will have more factors. The reason is that if we remove a particular factor (e.g., 3) from p − 1, it will not be present in p (as it is prime), so it must be present in p + 1 (same for other prime factors, only with a decreasing probability).

32 6. RSA key analysis

Figure 6.2: We used scatter graphs to show the dependency between the first and the second biggest factors of p − 1. The different patterns were observed. Starting from the left, two biggest factors of p − 1 generated at a) completely random; b) random but removing small primes; c) with at least one large prime factor with fixed length (e.g., 101 bits).

33 7 Summary

The main aim of this thesis was to extend the JCAlgTest tool used for gathering performance characteristics from JavaCard cryptographic smart cards. We identified issues related to the testing and provided two solutions how the execution time of operation can be measured. The JCAlgTest tool was extended with functionality for generation of various outputs (6) which were used to create new project website [20]. Collected raw performance data were processed to create six types of results presentation. From simple, such as execution time of particular algorithm, to more complex like overall performance visualised in radar graph. Further, we produced graphs showing dependency behaviour between the length of data and the operation time. We compared performance similarity among 20 tested cards. Our recommendations which card to choose for particular algorithm are available at the end of Chap- ter 5. All results can be easily re-generated when newly measured data are obtained. The second part of the thesis is dedicate to the analysis of RSA keys. We factorised over 200 000 of p − 1 and q − 1 values to obtain factor properties. We discussed possible vulnerabilities, showed differ- ences among generated keys and checked the compliance of standards requirements like NIST 186-4.

7.1 Proposed future work

Performance testing could be more efficient if some analysis is performed directly during the testing. Other benefits would be brought by an on-line service where gathered data are uploaded directly from the JCAlgTest tool by user (to eliminate manual sending of results). The JCAlgTest could provide automatic card recognition based on algorithm support together with immediate card comparison to previously tested cards. Functionality for identification of broken card from a batch of supposedly identical cards could be also extended. Mentioned enhancements are meant to increase the number of tested cards in the project database.

34 Bibliography

[1] Cameron F. Kerry and Charles Romine. FIPS PUB 186-4 Digital Signature Standard (DSS). 2013. url: http://nvlpubs.nist.gov/ nistpubs/FIPS/NIST.FIPS.186-4.pdf (visited on 05/10/2016). [2] ANSI X9.31-1998: Public Key Cryptography Using Reversible Algo- rithms for the Financial Services Industry (rDSA). 1998. [3] International Organization for Standardization. Identification cards – 7816-1–15. [4] K. Mayes and K. Markantonakis. Smart Cards, Tokens, Security and Applications. Springer US, 2007, pp. 56–72. isbn: 9780387721989. url: https://books.google.cz/books?id=9iwFQarJdBMC. [5] Oracle. Java Card Overview. 2016. url: http : / / www . oracle . com/technetwork/java/embedded/javacard/overview/index. html (visited on 05/04/2016). [6] Virtual Machine Specification, Classic Edition. Oracle. May 2015. url: https://docs.oracle.com/javacard/3.0.5/JCVMS.pdf. [7] Inc. GlobalPlatform. GlobalPlatform. 2016. url: https : / / www . globalplatform.org/ (visited on 05/05/2016). [8] International Organization for Standardization. Identification cards – Integrated circuit cards – Part 4: Organization, security and com- mands for interchange. url: http://www.iso.org/iso/catalogue_ detail.htm?csnumber=54550 (visited on 05/15/2016). [9] Jan Krhovják. “Problematika náhodných a pseudonáhodných sekvencí v kryptografických eskalačních protokolech a imple- mentacích na čipových kartách”. Diplomová práce. 2005. url: http://is.muni.cz/th/39510/fi_m_b1/ (visited on 05/04/2016). [10] Oracle. System (Java Platform SE 8). 2016. url: https://docs. oracle.com/javase/8/docs/api/java/lang/System.html (visited on 03/27/2016). [11] Petr Svenda et al. “The Million-Key Question - Guessing Cards from Keys”. In: 2016, pp. 4–5. [12] Karol Kubanda. Porovnanie rýchlosti kryptografických operácií na čipových kartách. Bakalářská práce. 2008. url: http://is.muni. cz/th/143339/fi_b/ (visited on 04/03/2016).

35 BIBLIOGRAPHY

[13] Lenka Kuníková. Automatické testování výkonnosti čipových karet s platformou JavaCard. Bakalářská práce. 2014. url: http://is. muni.cz/th/396278/fi_b/ (visited on 04/03/2016). [14] MESURE. Mesure Project website. url: http://mesure.gforge. inria.fr/Eng/GettingStarted (visited on 04/03/2016). [15] Jan Hajny et al. “Performance Evaluation of Primitives for Privacy- Enhancing Cryptography on Current Smart-Cards and Smart- Phones”. In: Revised Selected Papers of the 8th International Work- shop on Data Privacy Management and Autonomous Spontaneous Security - Volume 8247. New York, NY, USA: Springer-Verlag New York, Inc., 2014, pp. 17–33. isbn: 978-3-642-54567-2. doi: 10.1007/978-3-642-54568-9_2. url: http://dx.doi.org/10. 1007/978-3-642-54568-9_2. [16] P. Dowland and S. Furnell. “Advances in Communications, Com- puting, Networks and Security Volume 10”. In: University of Ply- mouth Press, 2013, pp. 45–57. isbn: 9781841023588. url: https: //books.google.cz/books?id=iOAQBgAAQBAJ. [17] S. Mangard, E. Oswald, and T. Popp. Power Analysis Attacks: Revealing the Secrets of Smart Cards. Advances in information security. Springer US, 2008. isbn: 9780387381626. url: https: //books.google.cz/books?id=YXkASFjeUswC. [18] David Komárek. “The RSA key generation process via power analysis”. June 2016. [19] Petr Švenda. Performance testing methodology. 2015. url: https: //github.com/crocs- muni/JCAlgTest/wiki/measurement_ overview.png (visited on 03/28/2016). [20] JCAlgTest. JCAlgTest - Java Card Algorithm Test. url: http : / / jcalgtest.org (visited on 05/01/2016). [21] Inc. GitHub. Contributors to crocs-muni/JCAlgTest. url: https:// github.com/crocs- muni/JCAlgTest/graphs/contributors (visited on 04/10/2016). [22] Petr Švenda. “Nuances of the JavaCard API on the cryptographic smart cards–JCAlgTest project”. In: (2014). "17th International Workshop on Analysis of Security API, ASA’14, Vienna, A satellite workshop of CSF 2014". [23] Dan Cvrček and Petr Švenda. “Architecture Considerations for Massively Parallel Hardware Security Platform”. In: The 5th Inter- national Conference on Security, Privacy, and Applied Cryptography

36 BIBLIOGRAPHY

Engineering (SPACE’2015), LNCS 9354. Springer, 2015, pp. 269– 288. doi: 10.1007/978-3-319-24126-5_16. [24] Martin Paljak. GlobalPlatformPro. url: https://javacard.pro/ globalplatform (visited on 04/30/2016). [25] Oracle Corporation. NetBeans IDE - Overview. url: https : / / netbeans.org/features/index.html (visited on 04/30/2016). [26] Mike Bostock. D3.js - Data-Driven Documents. url: https : / / d3js.org/ (visited on 04/30/2016). [27] Google. Charts | Google Developers. url: https://developers. google.com/chart/ (visited on 04/30/2016). [28] Jacob Thornton Mark Otto and Bootstrap contributors. Boot- strap | The world’s most popular mobile-first and responsive front- end framework. url: http : / / getbootstrap . com/ (visited on 04/30/2016). [29] Carlos Federico Cid. “Cryptanalysis of RSA: A Survey”. In: Infor- mation Security Reading Room. SANS Institute, 2003. url: https: //www.sans.org/reading-room/whitepapers/vpns/cryptanalysis- rsa-survey-1006. [30] R. L. Rivest, A. Shamir, and L. Adleman. “A Method for Ob- taining Digital Signatures and Public-key Cryptosystems”. In: Commun. ACM 21.2 (Feb. 1978), pp. 120–126. issn: 0001-0782. doi: 10.1145/359340.359342. url: http://doi.acm.org/10.1145/ 359340.359342. [31] J. M. Pollard. “Theorems on factorization and primality testing”. In: Mathematical Proceedings of the Cambridge Philosophical Society 76 (03 Nov. 1974), pp. 521–528. issn: 1469-8064. doi: 10.1017/ S0305004100049252. url: http://journals.cambridge.org/ article_S0305004100049252. [32] YAFU: YetAnother Factorization Utility. 2013. url: http://sourceforge. net/projects/yafu/ (visited on 04/10/2016). [33] Hugh C. Williams. “A p + 1 Method of Factoring”. In: Mathe- matics of Computation. Vol. 39. American Mathematical Society, 1982, pp. 225–234.

37 A Data attachment

The data attachment is available in the thesis repository1. It contains following:

∙ JCAlgTest Copy of JCAlgTest project repository (GitHub, 2016-05-18).

∙ JCAlgTest website Project website which contains all generated results (2016-05-18).

∙ Thesis Thesis text source files including used images and bibliography.

∙ RSAfactorization Factorised data with generated graphs.

1. http://is.muni.cz/th/422581/fi_b/