Bug #5550


EF.ARR file decoding would need to be context dependent

Added by chrysn 14 days ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


A record in EF.ARR can only be understood properly when it is known what it is used for (the audience in certificate parlance; whether it's used by an EF or a DF). Semantics vary widely -- an AM=0x01 in a record used by an EF means "read access" (ISO/IEC 7816-4:2005(E) table 16), whereas the same value interpreted by a DF or MF means "delete child file" (ISO/IEC 7816-4:2005(E) table 17).

Currently, pysim always interprets records as if they were used for an EF.

Changing this is likely hard, as the information needed to make the decision is simply not available. (A highly devious card author might even use the same rule for different purposes, but such a polyglot use we could probably ignore).

Potential solutions, probably in increasing complexity:
1. Do nothing; document that we're always assuming an EF type (and expect the user to do the necessary adjustments).
2. Use more general terms -- "bit1" instead of "write_append" (still work for the user, but not easily confused).
3. Use more general terms in output, but accept the type specific terms in input.
4. Accept input from the user in `read_record[s]_decoded` on how to interpret the record; using "bit1"-style output in absence of such input.
5. Keep tabs on which of the previously seen files refer to which record in an EF.ARR, and use that as default decoding style. (And warn/err if the type specific terms are used on a record that is referenced by a different type).

How much effort to put into this depends on the general usage patterns which I'm not familiar with yet. I can probably apply any solution (possibly with a bit of guidance as to the intended architectural decisions), but would need guidance as to which solution make sense here.

No data to display


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)