RVS Seminar Deployment and Performance Analysis of JavaCards in a Heterogenous Environment. Carolin Latze University of Berne

Transcription

1 RVS Seminar Deployment and Performance Analysis of JavaCards in a Heterogenous Environment Carolin Latze University of Berne

2 Table of contents > Introduction Smartcards > Deployment Overview Linux Windows JavaCard Applet Client Application > Measurements Scenarios Comparison Communication Protocol > Conclusion 2

3 Smartcards > Provide dual factor authentication > Storage of additional keys > Consist of a CPU, ROM, RAM, I/O unit and EEPROM > Transmission protocol: Application Protocol Data Units (APDUs) over Transmission Protocol Data Units (TPDUs) Command APDU: CLA INS P1 P2 Lc Data Le Response APDU: Data SW1 SW2 3

4 Smartcards by Schlumberger > Cryptoflex Cards Minimal fs Standart set of commands RSA, DES, T-DES, SHA-1 > Cyberflex Access e- gate32k Programmable using JavaCard RSA, DES, T-DES, SHA-1 > Compliant to ISO7816 which is the standard for SmartCards 4

5 Overview Client App Middleware Applet Client Machine Smartcard 5

6 Deployment under Linux > MuscleCard Framework Middleware to communicate and work with the card > Completely open source > Works fine with Cryptoflex Cards and older Cyberflex Cards Client App Middleware Applet 6

7 Deployment under Windows > SDK provided by Schlumberger > Can be used as client to test an applet > Provides libraries to communicate with the card Client App Middleware Applet 7

8 JavaCard > Subset of Java -> no garbage collection!!! > A JavaCard Applet has to implement the following functions: install(), select(), process() > Additional requirements: Specification of the CLA and INS Bytes: final static byte MY_PROJECT_CLA = (byte)0x90; final byte PIN_CHECK = (byte)0x10; final byte RSA = (byte)0x20; final byte DES3 = (byte)0x30; final byte DES = (byte)0x40; final byte SHA = (byte)0x50; final byte SIGN_TEXT = (byte)0xa0; Client App Middleware Applet 8

9 JavaCard Applet Control Flow Select APDU APD U 0x9000 (3) (7) process() (10) JCRE (6) true (5) select (1) install() Applet (8) works (4) looks for the AID (2) register() DB (9) returns control Client App Middleware Applet 9

10 Our JavaCard Applet > Provides the following cryptographic functions: RSA using a 1024 bit key DES T-DES SHA-1 Verify method of SHA-1 had to be implemented by ourselfes Message signing and ciphering using SHA-1 and RSA Client App Middleware Applet 10

11 Client Application > We decided to implement the client in Java Easiest way Speed is negligible > Required functions are provided by the slb.iop library Client App Middleware Applet 11

12 Measurements - Scenarios > Scenario 1 (DES, T-DES): 8 Bytes long input (randomly generated) 50 times encoding and decoding > Scenario 2 (RSA, SHA-1): Encoding: Different input lengths (50 times each) Decoding: Valid input required Middleware expects the number of bytes in the response APDU 12

13 Measurements - Encodings Time needed in ms DES T-DES RSA SHA-1 Message Number of Repetition Algorithm Mean Value (ms) Deviation (ms) DES T-DES Message RSA SHA

14 Measurements - Decodings Time needed in ms DES T-DES RSA SHA-1 Message Number of Repetition Algorithm Mean Value (ms) Deviation (ms) DES T-DES Message RSA SHA

15 Measurements Communication Protocol Time needed in ms Sending and Receiving an APDU Resetting the card Number of Repetition 15

16 Measurements Stress Test > Stress Test: 1) RSA (9* ) times 2) DES 100 times 3) T-DES 100 times 4) SHA-1 (9* ) times => ERROR 5) Message 9*50 times => ERROR => Reset is needed after each type of ciphering! 16

17 Conclusions > Issues: Bad documentation Meaningless error messages (6F00) Required memory has to be allocated before usage Different number representations Platform dependent Not compliant to the newest JavaCard specifications 17

18 Questions Thanks for your attention ;-) 18