Martin Paljak wrote: > 2010/3/20 Andreas Jellinghaus <a...@dungeon.inka.de>: > >> Hi Viktor, >> >> thanks for improving oberthur driver! >> a few questions: >> * is the code still limited to certain combinations of card/chip, card >> operating system and applet? or did this change expand the support? >> > It supports a specific applet. The wiki documents it > http://www.opensc-project.org/opensc/wiki/Oberthur >
It supports the AuthentIC applet (PKI applet)? This applet emulates the card file system, implements the ISO-7816 commands plus some card specific commands . The GlobalPlatform secure communication is accessible inside the applet and can be used to protect the access to the (emulated) files . Afaik, it's not the case for all the Java-cards (PKI applets?). For the outside world the fact that it's the JavaCard&Applet makes no difference. (Imho). > The way I understand it, ot was the pkcs15init capability to work with > non-native cards (pkcs15-init emu, similar to the read-only emu) that > got improved. pkcs15-init emu maps the write structure to match the > non-standard format. > Exactlly. In the case of Oberthur card no special needs to define the object files (paths, file-ids, ACLs for 'cert', 'key's, 'data') as it expected by the native Oberthur middleware. It can be described by the OpenSC card profile and existing API used for its creation. As for the non-pkcs15 object descriptors, the normal OpenSC init procedures, used to update the pkcs15 descriptors, need to be deviated to the alternative, card-specific procedures. It mostly concerns "update_any_df" and "update_token_info" . Finally it's possible (not actually implemented) to create both descriptor systems pointing to the same objects. Kind wishes, Viktor. -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
