Sim

historical

Hi,

I know that smart card EEPROMS are rated for 100k writes, but I would not
rely on that. In fact, this depends on how often is the EF.Kc file written,
which was my original question. Every 30 seconds or every day? Every day is
of course OK.

Additionally, how often are these other files written (LOCI, BCCH) ?

SmartCardFocus has a ID0 cutting service, that can turn any card into a SIM
sized module:
http://www.smartcardfocus.com/shop/ilp/id~82/p/index.shtml
This is the best option I know so far.

However for devel purposes, as layer 2-3 will be developed on a PC, most
people will need/use a PCSC reader and a normal sized card. Any javacard
will do, even dual interface cards such as JCOP31 or Cosmo or older
Cyberflex. my applet will have no specific requirement on javacard support,
JC 2.1.x or 2.2.x will do.

Regards
Sebastien

On Tue, Mar 16, 2010 at 9:20 AM, Dieter Spaar <spaar at mirider.augusta.de>wrote:

> Hello Sebastien,
>
> On Tue, 16 Mar 2010 00:09:46 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <
> squalyl at gmail.com> wrote:
> >
> > Sylvain, if I evolve your algorithm, then I think we don't need to store
> > anything in EEPROM. Just keep that in RAM and force a renegociation at MS
> > boot. What do you think of that?
>
> Just a question: Why do you want to avoid writing Kc to the EEPROM ? The
> cards I know have a quite huge number of EPPROM write cycles, e.g. for a
> certain MULTOS card the number is specified to be 500.000. I don't know
> the number for the card you use, but I expect it to be at least 100.000.
> For our purpose this should be really good enough, I would expect more
> writes to EF LOCI and EF BCCH than to EF KC.
>
> A question to the list: does anyone know where to get a tool to
> cut out a SIM from a standard smart card ? I don't prefer doing this
> with a knife or similar, this might only be OK for one or two pieces
> and the result also does not look too good.
>
> Best regards,
>  Dieter
> --
> Dieter Spaar, Germany                           spaar at mirider.augusta.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100316/23a0b100/attachment.htm>