Sébastien Lorquet squalyl at
Tue Mar 9 15:21:43 UTC 2010



Does the chip manages T=0 or T=1 by itself or do you have to implement it in

Indeed APDU are always exchanged. If the card doesn't answer, it's an error
condition. it should be reported by an error status return value. But the
complete exchange can be long, a card may send "time extension requests".

The reset procedure requires a dedicated API.

What about PPS, ie line speed negociation? This feature is described in
ISO7816-3, and also in TS 11.11 chapter 5.8.2.

Your driver need 4 functions:
-init driver
-stop driver
-reset card and return ATR
-exchange APDU
and, maybe
-suspend and resume, which can stop the clock.

I think official sim cards can be put in sleep state, that the clock can be
stopped, and this sort of energy saving stuff. I don't know a lot about
this, and we don't need this in a first version.

----- Update status for the on-card project: -----

Reminder : I'm using javacard 2.x.y

I'm still working on the file system implementation, I want it sufficiently
versatile for others projects too, so it's a bit long, but already working.
I have routines to create files and directories, support binary files,
record files and directories. I still need to create write() and read()
routines, but they are quite trivial.
I'm spending time on the file selection, even if the SIM spec supports only
a few modes.

The first goal is to have a basic applet that's the most ISO7816-4
compatible, then a sim specific version. The functionalities are equivalent
, but the apdu formats are a bit different.

The final goal is to have the ability to create any file structure (GSM or
not) holding any possible data, without neglecting security (of files, not
gsm algs ;) ).

Speaking of this, the COMP128 alg is already ported to javacard thanks to C
code available on the web. If someone has test vectors (IE encryption
results verified by someone else), I'll be happy to try them.

I still have a small doubt for high-update rate files. What is an high
update rate? Can this really wear a card's eeprom? I may have to create a
specific file type to implement wear levelling, using a log/cyclic
structure. I don't know the urgency level of this feature.


On Tue, Mar 9, 2010 at 3:12 PM, dexter <zero-kelvin at> wrote:

> Hi folks.
> I have now getting interrupts and i am sending the first little APDUs to
> the card. I think i will have something that basicly works soon. But up to
> now i think it will be impossible to save processing time during the
> transmission - wait phases without having semaphores (or something semilar
> that can be used to wait for an event without wasting processing time in a
> while loop.) However - this only makes sense with a multitasking os which we
> actually do not have ;-)
> The driver will get a function like sim_card_transceive(*message,
> *response) or so on because a transaction with the card will never be
> receive or send only. You always send something to the card and you always
> get something back.
> The response and answer apdu structures will be the same as in XCOS and i
> think i can reuse a lot of the good old XCOS header files that contain basic
> constants, returncodes ect...
> Thanks a lot to roh who showed me how i can register an interrupt.
> regards.
> Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the baseband-devel mailing list