On Tue, 2010-08-17 at 02:08 +0200, Emanuele Pucciarelli wrote: > On Tue, Aug 17, 2010 at 00:59, Andre Zepezauer <andre.zepeza...@student.uni- > > This particular card isn't important at all. But it shows, that the > > select_file function doesn't work for an iso card. I had to write code, > > to read the contents of this one. But I really would like to use > > opensc-explorer for such a task. For example: > > cat 2F00 > > cat 2F01 > > I still think it wouldn't be bad if you could give an example of what > does not work and what does, because then, perhaps, someone would be > willing to help implement the missing (or wrong) functionality – > especially as you've already written your own code. > > As far as debit cards are concerned (EMV), my experience is that > opensc-explorer does not work because it tries to select the Master > File upon startup. A small patch to let the user choose a different > file, or not file at all, at startup, would overcome that. (Surely > there would be other problems later.) I'm unsure about your example of > "cat 2F00, cat 2F01", because I'm under the impression that EMV cards > use file selction by name (and not by file ID), but I may very well be > wrong here.
The IIN is 672518 (Maestro debit cards (Germany)). I haven't looked close enough to be sure if it is a EMV. It has a MF (implicitly selected after reset), a lot of files (selected by fid) and a handful of application DFs (selected by aid/fid). The select command supports only the p1-values: 1: select df under current df 2: select ef under current df 3: select parent df 4: select df by name Cards which comply with chapter "9 Application-independent card services" of 7816-4 must implement 1,2,4. The preferred values used by the iso driver are 0,8,9. > > There is still the question, if this is the right place for a command > > not defined by iso. My answer is clearly not, because: > > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor > > can code it's own proprietary commands in this class. Which in turn > > leaves the possibility, that two different vendors define the same apdu > > command in two completely different ways. > > Yes, this is possible in principle, although many sensible COS > manufacturers (or even developers writing BasicCard/JavaCard applets) > would question the opportunity of defining a proprietary command > overriding an international standard (EN 726) that's been in place for > so long. But the point is moot, because… > > > 2. Not even a single card driver overrides iso_ops->give_random. So > > every driver would send this command down to the card. Which is not a > > good idea (see point one). > > …as far as I am able to tell, this means that no driver at all will > ever send this command to the card, until someone decides to use it > somewhere in the code. > > That said, I'll reiterate: if give_random is significantly > controversial, I won't object to removing it, as it isn't being used. > > Bye! > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
