C++ programmable smartcard

Card Products

Moderator: horse dream

Posts: 7
Joined: Sat Oct 20, 2018 9:17 am
Points :182

C++ programmable smartcard

Post by sdellava » Fri Mar 15, 2019 5:27 am

Dears, I need to program a SC using C++

The reason is that I've a complex code that is strong to be executed so I hope that a lower lever programming will be faster.

NFC interface needed.

Any suggestion ?


Posts: 138
Joined: Tue Sep 27, 2016 10:58 am
Points :1780

Re: C++ programmable smartcard

Post by tay00000 » Fri Mar 15, 2019 7:48 am

C based programmable smart cards are highly limited as 95% of the cards available in the industry is made up of JavaCard. You are better off using JavaCard as JavaCard is the industry standard for smart cards and almost every specification for card systems these days seems to revolve around JavaCard due to their dominant market shares.

That being said, there are still exotic cards like those for .NET, C/C++ and BASIC.

For C/C++, you can look for MULTOS type cards. They operate differently from JavaCard in the programming language use and their compiled format is MULTOS Executable Language instead of the usual CAP file.

If you are interested, take a look at this MULTOS card but do not expect anyone to support you here if you go down the road of MULTOS as MULTOS is part of the 5% market share that very rarely anyone would support (and this is a JavaCard forum ;) ).

Also note that the above mentioned MULTOS card does NOT have any contactless capability so you are stuck on a contact-only card if you use the above.

I have not seen any other type of C/C++ based cards (i.e. MULTOS based) except that one above.

Also, note that the MULTOS card compiles C/C++ to MEL bytecodes that are loaded to the card and it uses a MULTOS VM almost the same technology as JavaCard.

JavaCard converts Java-like syntaxes (instead of C/C++) to JavaCard bytecodes and is also loaded to the JCVM on the card with similar technologies.

It does not really matter if you program in C/C++ or JC or even .NET cards or BASIC cards because they all share a similar technology which is they will have to be compiled to some sort of in-between machine bytecode (not raw ASM/machine code) and then these machine level bytecodes are loaded into the VM of the card and the card converts it back to usable raw ASM/machine codes for the chip's CPU.

Does it affect speed ? May yes, maybe no ...... because you wont ever get the low level ASM/machine code ....

Unless ..... you decide to throw away the concept of the usual VM based format of JC/MULTOS/.NET/BASIC and so forth and you decide to create your very own firmware on the card from scratch but this will require NDA between you and the secure chip manufacturer (i.e. NXP/Infineon/STMicroelectronics etc ...) and then with the NDA and proprietary security chip development kit, you write your own Card OS and raw card firmware from scratch or with building blocks provided by the chip manufacturer which is a whole different story.

The above route of doing low level on-chip firmware is not just riddled with lots of NDAs and trade secrets but you have almost very little support. There are known stories of poor support cases because your net value for the chip manufacturer to profit is insignificant and they would simply put your support questions on the back burner.

I do suggest that if you have "complex code" and a "need for speed", you might want to look at the J3H145 and ask JavaCardOS to boost the speed from default 106 kbit/s to 848 kbit/s which should help. The J3H145 also comes with both contact and contactless.

As for the "complex code", you can approach the forum on how best to implement it in JavaCard. The above suggestion I give would definitely be the most suitable in terms of not needing to go through the trouble of doing low level chip firmware creation while also using a commonly available card language (JC).

I wish you the best of luck.

Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 2 guests

JavaCard OS : Disclaimer