On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: > On 14.01.2011 15:17, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 13:37, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > >>>> Hello Andre, > >>>> > >>>> On 14.01.2011 04:24, Andre Zepezauer wrote: > >>>>> please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of > >>>>> local and global PIN objects. There is no mention of storage location. > >>>> There is mention of 'path'. > >>>> The difference between 'global' and 'local' is that the first one can be > >>>> verified from any location on the card, > >>>> the second one is 'visible' only from somewhere under the DF (or > >>>> application) where it's defined. > >>>> > >>>> So, we need (or, if you like, it's useful) to have 'path' defined for > >>>> the local PINs, to be able to select it's path before verification. > >> My previous assumptions comes from this citation. > >> It seems that I am terribly missing something. Can you give more details? > >> > >> > >>>> From PKCS#15 6.8.2 Pin objects: > >>> "PinAttributes.path: Path to the DF in which the PIN resides. The path > >>> shall be selected > >>> by a host application before doing a PIN operation, in order to > >>> enable a suitable > >>> authentication context for the PIN operation. > >> That's 'local' PIN. > >> > >>> If not present, a card-holder verification > >>> must always be possible to perform without a prior `SELECT' > >>> operation." > >> That's the global one. > >> > >> > >> So we desperately need the 'path' for the local PINs. So that 'host > >> application' can select the path > >> 'before doing a PIN operation'. > >> You probably know another way to do verification from the random location > >> on the card ? > > Take Java Card with PKI applet as an example. Once the applet is > > selected, it is possible to perform the VERIFY command from every > > location within that applet. That's 'local' PIN too. Because it's only > > valid for that applet but not for the whole card. > > > OK, let us adjust the terminology. > I am talking about the PKCS#15 card. This card starts from some MF, where > exist EF.DIR, probably EF.ATR, ..., as well as application DFs. > The AID of application DFs are present in the EF.DIR records. > The global PINs are defined at the MF level or above, the local ones are > defined in application DFs. > > In my comprehension to create/use the PKCS#15 objects you don't need to jump > higher then MF, and thus to reset status of 'global' PINs. > You have another vision, examples ? > > > > BTW care must be take with re-selecting an applet in Java Cards, because > > it may invalidate all previously verified PINs. > > The AIDs of the applets of your Java Card, are they present in some EF.DIR ? > Can its be discovered by the procedure previewed by PKCS#15 ?
You only need to have a default applet that can handle "SELECT 2F00" and "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY NAME", which is handled by the runtime environment and switches form one applet to another. Now you can proceed with 5031 and 5032. The whole process is nearly transparent. There are only two issues I encountered so far: * there is no MF per default, but it could be simulated by the applets * "SELECT BY NAME" is handled by the Java RE which imposes it's own semantics for that command > Our card starts from EF.DIR. Everything that is above this file is out of > PKCS#15 context. > > > > > > Regards > > Andre > > Kind wishes, > Viktor. > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
