Andre Zepezauer wrote:
> On Thu, 2010-11-04 at 17:03 +0100, Viktor TARASOV wrote:
>
>> Andre Zepezauer wrote:
>>
>>> 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]
>>>
>>>
>> Thanks.
>>
>>
>>
>>>
>>>
>>>>> 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".
>>>
>>>
>> I was talking that, to update the pkcs#15 card contents,
>> there is (practically) no need of the information other then the on-card
>> pkcs#15 and ACLs .
>> It also concerns the composed ACLs -- no need of the extra-card
>> knowledge (CIAInfo.profileIndication -> <profile content>)
>> to get authentication for an operation .
>>
>> And so, no need to restrict OpenSC to the usage of the OpenSC
>> initialized cards.
>>
>>
>>
>>> Therefore please see 1. and 2. at the beginning of this thread.
>>>
>>>
>> 1. There is no sufficiently of logs to make any conclusion, it's can a
>> 'local' bug.
>> In any case the solution is excessively 'global'.
>>
>
> You can see from the logs that this is CardOS personalised with Siemens
> HiPath library (aka CardAPI v3.1). The security condition (SC) 116 that
> must be satisfied is a Logical Test Object. It's definition is something
> like this:
>
> [SC_116 is satisfied] if and only if [SC_115 OR SC_130 is satisfied]
>
For CardOS card,
can this rule be obtained from the card itself (through the ACLs, SE, ...)?
> Only SC_115 (0x73) and SC_130 (0x82) are references to pin objects, that
> can be verified with the VERIFY command APDU!
>
> The 'local' solution would be, to ignore the proprietary security
> attributes (tag 86 in FCI). And use the information from pkcs15 data
> structures instead. But point 2. from the above would still hold.
>
>
>> 2. Should be illustrated by example (with the detailed logs). If the
>> problem really exists,
>> imho, it's rather question of decoder/encoder of tokenInfo.
>>
>
> * encoding of LastUpdate is broken
> * SupportedAlgorithms has a fixed limit
> * RecordInfo, IssuerID, HolderID aren't recognised
>
> Why you need logs?
To see what was read from card, and what is trying to be written.
You did not mentioned before about the 'RecordInfo, IssuerID, HolderID,
...',
but this information could be obtained from the logs without additional
negociation.
> In example it's totally clear, that SeInfo,
> RecordInfo, SupportedAlgorithms, IssuerID, HolderID are never written to
> the card. Which effectively removes that information from the card, when
> OpenSC updates LastUpdate. Correct?
>
Correct,
so, the problem is in decoder/encoder of TokenInto ?
By the way, are you happy with the results that you've asked for:
http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015210.html
>
>>> [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
>>>
>
>
>
>
--
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
