I use NXP JCOP smart-cards for prototyping in my research. I have recently benchmarked the cards using my research code, which contains computational and cryptographic workloads.
I found a couple of surprising results that I want to share, so fellow developers can make informed decisions when choosing their prototyping platforms.
There is a 1.5-2x speed difference between the different revisions of the same high-end chip, the NXP JCOP41 with 72kb of EEPROM. The V2.2 revision for smart-cards (no longer available, replaced by 2.2.1) has the best performance, and the V2.2.1 revision for the SIM (ID 000) form factor has the worst performance.
There is a significant speed difference between the same revision (V2.2.1) of the same chip (NXP JCOP41, 72kb of EEPROM), in different form factors. The chip for the smart-card form factor is almost as fast as the older V2.2 revision, while the chip for the SIM (ID 000) form factor is significantly slower.
There is a 2-4x speed difference between the same revisions (V2.2, smart-card form factor) of the NXP JCOP31 and the NXP JCOP41 chips.
The 3DES encryption/decryption engine has non-linear performance. The time it takes to decrypt 128 bytes is not very different from the time it takes to decrypt 24 bytes, on the JCOP41 chips. It seems that there is a huge setup cost for the DES engine, which outweighs the actual encryption cost.
There is a 4-8x speed difference between RSA and 3DES encryption on the JCOP41 chips, and a 3x speed difference on the JCOP31 chip. This goes against the conventional wisdom that symmetric encryption is 2 orders of magnitude faster then asymmetric encryption. This is probably due to the time it takes to setup the 3DES engine.
Secure processors in smart-cards have non-obvious performance characteristics. I hope my work saves you from the unpleasant surprises that I had.
To the best of my knowledge, there are no easy to get benchmarks on smart-card processors. At least, I couldn't find anything when I searched.
Smart-card retailers disclose vital specifications, like EEPROM size and the cryptographic primitives that are implemented on the chip, but tend to be quiet about speed. The sites I used don't mention anything about the type of processor used, or the frequency of the processor.
For some applications (e.g. prototyping, where I want my unit tests to run quickly), speed is just as critical as the other specifications, and its more important than cost.
The data that I used to reach my conclusions is available below. The benchmarks are described in section 5.1 (page 13) in my paper on a successor to the TPM.
decrypt_3des decrypts 24 bytes of data, while decrypt_3des_long and decrypt_rsa work on 128 bytes of data. 3DES is configured in EDE-CBC mode (112 bits of key material) and uses the ISO-9797 method 2 for padding. RSA decryption uses PCKS#1 padding.
The benchmarks can be reproduced by installing Rubygems, then installing the tem_ruby gem, and issuing the following commands
tem_upload_fw # Uploads my JavaCard applet to the active smart-card.
tem_bench # Runs the benchmarks.
NXP JCOP41 v2.2/72k (no longer available)
NXP JCOP41 v2.2.1/72k (usasmartcard.com product link)
NXP JCOP41 v2.2.1/72k USB token (usasmartcard.com product link, probably using this card)
NXP JCOP31 v2.2 (usasmartcard.com product link)
I'm also playing with JCOP cards, and already have JCOP 41 2.2.1 cards. Do you know where I could purchase the new JCOP 41/31 with the OS 2.3.1 or 2.4.1 from NXP? It seems impossible to locate where to buy those cards.
Thanks in advance.
@jax: I read about the new cards, but I don't know where to find them, either. I'd like to get my hands on them too, to see if they're faster, and if they have AES.ReplyDelete
Sorry I can't be of any help!
Your measurements can be hardly taken to proof that JCOP performance depends on the interface. You don't have the knowledge about the configuration of JCOP for the products you measured and not even the underlying chip technology. Here are some comments to think:ReplyDelete
- JCOP v2.2.1 includes more security countermeasures
- Underlying HW platform, the SmartMX, has asynchronous design. Specifically it affects performance in the 'free running mode', where the chip runs as fast as possible depending on the energy it has.
- Most performance issues are based on the applet coding style (key and cipher initialization, memory usage, ..,). I cannot find the source of your performance applet (tc.cap).
- You're not only measuring the smart card OS, but also your off-card program, computer and reader.
- There is not much information on your test strategy and equipment used.
- The statement that native it would be "likely on the order of 20X" is highly speculative without any proof.
@lexdabear: Thank you for your feedback! I have seen your posts in various smart-card forums, and I know you are very knowledgeable on smart-card issues. I am honored that you read my blog post, and I'm sorry if the contents is confusing.ReplyDelete
My main point was that if you're a smart-card application developer, it's very hard to know the performance of the chips that you're buying.
I supported this main point with examples where different revisions / configurations of the same chip gave different performance results.
I did not say that the software must be slower. There's certainly a possibility that very different chips are marketed under what appears to be the same name. My point was that developers need to know this, and need to measure the performance on the exact chip they're getting.
The source code for the JavaCard applet that I measured is at http://github.com/costan/tem_fw and the driver is at http://github.com/costan/tem_ruby/ (the benchmarks are in lib/tem/benchmarks).
In my TEM paper, I say that the bytecode interpreter that I wrote in JavaCard would likely run 20x faster if it ran directly on native hardware. I did also say that crypto is probably implemented natively, and would not get the same speed-up.
I came up with the 20X number based on what I figured the JavaCard VM has to do to run my interpreter, versus what my interpreter would look like if I could code it in assembly or do native code generation.
I'm wondering if you could help me get my hands on the proper SDKs to write native code for these chips. Then I could port my application, measure, and remove the speculation.
I tried approaching Atmel and Infineon, but I'm having trouble getting them to pay attention to my request. That's probably because I'm a PhD student, and I don't have an order of 1 million units.
It's disappointing and a bit infuriating that cable pirates have SDKs for these smart-card chips, but a security researcher like me can't get them. Do you think you could help me get my hands on an SDK?
Thanks so much!
Can you put somewhere applets you used in speed testing? I have some Gemalto TOP cards and would like to compare performance with JCOP.ReplyDelete
your blog is very nice Well, it’s amazing. The miracle has been done. Well done.ReplyDelete
Does anyone know where I can find deep technical information about smart cards?. I'm doing a report for the company I'm working for.
I am also new to java card development.i am playing with jcop 31/36 contact less smart card.i encrypted some data from the card using RSA.when i used RSA-2048 it will always give some exception it seems to be it needs some high power consumption.then i used RSA-512 algorithem.then It works but most of the times i can't receive the data.some times it returns 64 bytes.i am used nexus s phone to send the data.i want to know what is the low power consumption java card in jcop cards.(contactless)