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?
> 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 .
> Regards
> Andre
>
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
