COS File System

[Harald Welte]

Hi Tom,

On Sat, Nov 30, 2013 at 10:45:04AM -0500, Tom Schouten wrote:
> On 11/28/2013 02:43 PM, Harald Welte wrote:
> >I would not want to have c structs for read only files.
> >
> >Normal cards have a pre personalization state in their life cycle where you can create any EF and df based on APDU from a PC/card reader.
> >
> >All permission bots, type and structure of file, etc are defined at that time, including allocation of memory, etc.
> 
> I'm guessing that the pre-personalization stage is not standardized
> so we'd have to invent an approach.

The detailed encoding of the APDUs and permission bits is normally not
standard across vendors/products, but the general idea of having a
pre-personalization stage and creating files with a "CREATE FILE" APDU
is fairly generic.

This enables you to add files like for example those that differentiate
an ISIM (LTE) from an USIM.  Or what differentiates a TETRA SIM from a
GSM SIM.  Or GSM-R form GSM.

> I'm a big fan of "dumb firmware" for deeply embedded devices, so I
> wonder if in this case it makes sense to simplify fw by avoiding to
> specify a complex protocol for the pre-personalization stage.

I don't think it would be that complex.  The permission bits, file
structure, size, etc. (file control template) are encoded the same way
as you have to present them in the responses to SELECT.

As you need to parse those bits anyway during read/write access to the
file. having code that takes those bits as a blob from the CREATE FILE
command and stores them to flash is probably not overly complex either.

What is different though is the way you allocate memory to files, as you
do not a priori know the number of files and all their sizes.  Only
after all CREATE FILE have been issued.

> What about this:
> - compile high level specification to nested C structs on host PC

I wouldn't even bother having eny encoding of all this (very complex!)
information that differs from the wire format as specified in 7816-4 and
the respective ETSI and 3GPP specs.  So rather than having c structs
with tons of optional sub-structs and bit fields, sub-arrays, etc. I
would simply use the same binary encoding and implement run-time
accessor/parser functions.

But then, I am unlikely to be able to contibute much, I'm just sharing
some of my thoughs from working with smartcards and sim cards for a long
time...  So in the end it is of course the person that implements it who
makes the decisions!

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)