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'.
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.
>
> In short, opensc is sufficient to do sign/decrypt operations but it is
> weak on writing.
>
I do not see 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
>
>
--
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
