squalyl at gmail.com
Tue Mar 9 15:25:11 UTC 2010
Something more of a note for later:
I don't know which GSM stack layer needs to exchange APDUs. I guess it's not
level 1, so apdus will be exchanged through the serial link with the phone.
It may be nice to have a pcsclite driver to drive the sim card in the phone.
Then we'll be able to use a SIM cards connected to the real phone, or a ccid
smart card reader connected to the PC running the layer2/layer3, using the
On Tue, Mar 9, 2010 at 4:21 PM, Sébastien Lorquet <squalyl at gmail.com> wrote:
> Does the chip manages T=0 or T=1 by itself or do you have to implement it
> in software?
> 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 gmx.de> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel