On Thu, 2010-11-04 at 09:48 +0100, Viktor TARASOV wrote:
> Andre Zepezauer wrote:
> > On Wed, 2010-11-03 at 18:54 +0100, Viktor TARASOV wrote:
> >
> >> Andre Zepezauer wrote:
> >>
> >>> On Tue, 2010-11-02 at 09:05 +0100, Ludovic Rousseau wrote:
> >>>
> >>>
> >>>> 2010/11/1 Andre Zepezauer <andre.zepeza...@student.uni-halle.de>:
> >>>>
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> the pkcs15init tool currently writes to cards, even when the profile
> >>>>> indication (3F00/5015/4946) isn't found. That's bad, because it's highly
> >>>>> possible that such a card was personalised with another library or has
> >>>>> an unknown profile. In my opinion there are the following issues:
> >>>>>
> >>>>> 1. opensc isn't smart enough to do such things (see #252)
> >>>>> 2. after a successful write operation the TokenInfo is overridden, which
> >>>>> * is incomplete and
> >>>>> * contains broken ASN1 encoding
> >>>>>
> >>>>> The attached patch prevents that behaviour and fixes #252. It is for
> >>>>> current trunk. But should work for 0.11.13 too.
> >>>>>
> >>>>>
> >>>> Fixed in revision 4853.
> >>>>
> >>>> I have not closed ticker #252 because I am not sure the problems are
> >>>> related. (and I have not read ticket #252 in detail).
> >>>>
> >>>>
> >> Neither do I.
> >> It would be nice to have full logs and to get know what's going on between
> >> 'Please enter Unspecified PIN ...'
> >> and
> >> '... cardos_check_sw: function/mode not supported'
> >>
> >>
> >>> The user reporting the bug has a card manufactured by Siemens.
> >>> Personalisation was done by the card vendors software (HiPath).
> >>> Therefore the card doesn't have the file 3F00/5015/4946 on it. With this
> >>> patch applied, the output of pkcs15-init looks like this:
> >>>
> >>> $pkcs15-init --generate-key rsa/1024 --auth-id 01 -v
> >>> Using card driver Siemens CardOS.
> >>> Couldn't bind to the card: File not found
> >>>
> >>> This is the correct behaviour, because the profile indication
> >>> (3F00/5015/4946) is missing. And refusing to modify cards without
> >>> knowing the exact profile, is good practise anyway.
> >>>
> >>>
> >> Imho, the main reason to use PKCS#15 is interoperability between different
> >> card and middlewares in the card initialization and card using, and so,
> >> OpenSC should operate with the cards initialized by other middlewares.
> >>
> >
> > Agreed.
> >
> >
> >> Probably the on-card profile indication should be removed at all
> >> (afais, it's main purpose is to distinguish 'one-pin' and 'normal'
> >> pkcs15 profile).
> >>
> >
> > Yes, the *current* profile indication should be removed. It should be
> > replaced with the mechanism according iso-7816
> > (CIAInfo.profileIndication). When doing it the right way, it would
> > benefit interoperability. Let me explain:
> >
> I have no this ISO.
> What's the difference between CIAInfo and TokenInfo?
See yourself:
* pkcs15 v1.2 draft [1]
* iso-7816-15 draft [2]
> > For example an implementation with full support of ACR (access control
> > rules) could specify something like this:
> > Access to an object X is granted, if A_01 && A_02 && not(A_03) has been
> > verified. Where A_01 uses pin-authentication and A_02 uses
> > external-authentication and A_03 must not have been verified at all.
> > With different security environments it is even more complicated.
> >
>
> Until now, in the card specification, I've seen the possibility like this:
> (A_01 && A_02 && ...) || (A_03 && A_04 && ...),
> on the real cards
> (A_01 && A_02) or (A_01 || A_02 || ...)
>
>
> In the real cards I have not seen the authentication objects with
> methods other then PIN to be represented in PKCS#15 structure.
> (There was vague notion 'integrity-protected' in the PinFlags, but no
> the corresponding authentication object)
>
> And so, in my mind:
> -- the upper levels (pkcs#15 and pkcs#11) should deal only with PINs.
> Logical operations with PINs still need to be implemented by
> OpenSC/pkcs#15,
> it needs some clever interaction with pin cache, pin status ('verified',
> 'blocked', ...), ...;
>
>
> -- the other authentication methods are managed by the low card level
> (libopensc).
> It's in this manner the SM (and soon the Ext.Auth) is implemented in the
> IAS/ECC branch.
>
>
> > Not every implementation would understand this, for sure. Therefore
> > profile indication could be uses to indicate a specific coverage of
> > features an implementation must understand. Do you know of any such use
> > of profileIndication? I would assume that such things still exists. In
> > example defined by national agencies.
> >
>
>
> For me the profile indication is the AID. In the IAS/ECC branch it used
> to find out the particular pkcs15init card profile .
> Strictly speaking, this profile is needed only to fix ACLs for the data
> (EF or SDO) of the new objects.
>
> Until now, in all of these profiles (on-card applications) all the
> needed information could be found in pkcs#15 or in ACLs .
Nevertheless this thread is not on reading of on-card data structures,
instead it's topic is "modification of on-card data structures".
Therefore please see 1. and 2. at the beginning of this thread.
In short, opensc is sufficient to do sign/decrypt operations but it is
weak on writing.
[1]
ftp://ftp.cert.dfn.de/pub/docs/crypt/PKCS/ftp.rsa.com/pkcs-15/pkcs-15v1_2.doc
[2] http://www.page9.webaxxs.net/iosis/isodrafts/17n2109t.pdf
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
