sim client

Sébastien Lorquet squalyl at
Tue Aug 17 16:20:27 UTC 2010


I am OK with your ideas, with some remarks:

- please rename WRITE to UPDATE. Writing is the process of flipping bits
from "0" to "1" in a file, resulting in a logical OR between the old data
and the new data (AND-writing also exists). An erase is needed to flip these
bits to zero. Update is the process of overwriting old data with new data.
The concepts are clearly separated in ISO7816, and the GSM 11.11 spec does
not support writing to a SIM but only updating (which is good :)). This is
only a wording issue, and I will not kill a kitten if someone prefers to
keep the "write" wording.

- the uint16_t file shall be a path, ie uint16_t path[MAX_SIM_PATH_LENGTH]
where MAX_SIM_PATH_LENGTH is a small constant, ie 4 or 6.
rationale: normal UICCs only have a single telecom and a single gsm DF. But
we might want to develop multi-DF SIMs, ie one DF for the normal carrier,
and another one for an OpenBSC network. Storing a file_id and a df_id is
another option, but DFs can be nested so I don't like it because it's too

-what about incoming data? This should be stored inside the job. On an
update job, the callback will tell you that the update was completed, but
you have to send the data anyway. Let's call that the job payload.
Unfortunately GSM11.11 tells that updates can be 255 bytes long, which is
annoying if such a long buffer is needed, I agree. Something smaller may
fit, we will never update 255 bytes at once. The offset at which to update
must be also stored. GSMKEY and PIN operations will also need this incoming

-what about PIN presentation? This should be a separate job type, with the
PIN code as job payload. Okay, this is not needed in a first version.

-there are two file types. Transparent and record files. The first one are
"classic" files, the other are typically accessed one record at a time (e.g.
phonebook entries) What about these access differences? We can abstract this
differences if we know the record size via a separate call or job type.


On Tue, Aug 17, 2010 at 5:33 PM, Andreas.Eversberg <
Andreas.Eversberg at> wrote:

>  hi,
> i like to write the sim client protocol. i do not mean the code of the "sim
> reader" which is part of layer1 inside the phone. before i start, i would
> like to know what you think about my api idea. the api is not the low-level
> api between layer1 and the mobile application (APDU layer). it describes a
> higher layer for application or protocol processes which need to request
> IMSI, do key generation, or store location area information.
> one important thing is that different processes must be able request
> "read", "write", or other operations like key generation simultaniously. in
> order to handle multiple requests after each other, a queue inside sim
> client must exist. afterwar processing each request, the result must be sent
> only to the requesting process (if it still exists). a state machine
> watches over the current DF (current selected file area of the sim) and
> changes current "DF" if required, before processing read or write job. also
> it triggers the next job in the queue, if finished with the current one.
> *int handle = sim_open(void (*cb)(...))*
> will add a new user instance. cb is the function to be called for response,
> handle is a unique id of the process (not a memory pointer, unique at all
> times after starting phone).
> *void sim_job(struct msgb *msg)*
> **
> *struct sim_job_hdr {*
> *    int handle;*
> *    uint8_t job_type;*
> *    uint16_t file;*
> *};*
> will add a new job. the type defines the job type. examples are "READ"
> "WRITE" or "GSMKEY" requests. the handle is used to assign the read/write
> job to an instance. the file is used to select the correct data file of the
> sim. the data and len represent the data to be written.
> *void cb(struct msgb *msg)*
> is called back by the sim client when job is done. the handle is given, so
> multiple user  instances may use the same callback.
> *void sim_close(int handle)*
> will remove user instance. outstanding jobs will finish, but no result is
> given, because cb is now unregistered.
> the coding and decoding of SIM files must be done by the application or
> protocol layer that use the sim client.
> andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the baseband-devel mailing list