Le 28/04/2011 11:02, NdK a écrit :
> On 25/04/2011 11:01, Viktor TARASOV wrote:
>
>>> For what I've understood, "-a N" makes $PIN in profile be replaced by
>>> CHVN, hence IMO --insecure<=> $PIN->NONE.
>> No,
>> '-a N' means in fact '-a<ID of authentication object> .
>> The real PIN reference, the one that can be used in the PINs APDU,
>> is extracted from AODF record as PinAttributes.pinReference .
>>
>> The 'N' in the CHVN syntax is directly pin reference that corresponds to
>> PinAttributes.pinReference .
> Ok.
> Too bad it seems not to work this way, and $PIN anlways gets translated to
> CHV1 :(
$PIN, $SOPIN and others are the profile macros and correspond to the
SC_AC_SYMBOLIC authentication method.
They are resolved using the pin flags of the PIN pkcs15 objects already present
on the card.
Look into sc_pkcs15init_get_pin_reference() .
If your card contains the User PIN authentication object with the reference 1,
the $PIN is translated to CHV1.
> If I do
> $ pkcs15-init -G rsa/2048 -a 02 -l "test a2"
> the card still requires verification of CHVN1 to use the card.
'-a 02' only (to be confirmed) means that the CommonObjectAttributes.authId of
your object will be set to '02' and written to the PrKDF .
Look into you profile (which one?) -- how generation/creation of new
file/object is protected in your parent DF?
how write operation for xxDFs is protected ? ... If one of them is protected by
CHV1 ($PIN) -- you will be asked for CHV1.
> PINs are defined as:
> PIN [Card auth]
> Object Flags : [0x3], private, modifiable
> ID : 01
> Flags : [0x30], initialized, needs-padding
> Length : min_len:4, max_len:8, stored_len:8
> Pad char : 0xFF
> Reference : 1
> Type : ascii-numeric
> Path :
>
> PIN [User auth]
> Object Flags : [0x3], private, modifiable
> ID : 02
> Flags : [0x30], initialized, needs-padding
> Length : min_len:4, max_len:8, stored_len:8
> Pad char : 0xFF
> Reference : 2
> Type : ascii-numeric
> Path :
> so -a 02 should make $PIN get translated to CHV2, not to CHV1 as it
> does. Or am I wrong?
See above.
>> Personally, I'm ready to remove at all 'insecure' option -- never used it.
>> All the stuff can be defined in the card profile. But let us wait for the
>> other opinions.
> I could finally workaround non-working-as-advertised --insecure by
> patching profile and w/o touching code:
>
> option default {
> macros {
> [...]
> prkacl = CRYPTO=$PIN, UPDATE=$PIN, DELETE=$PIN,
> GENERATE=$PIN;
> }
> }
>
> option insecure {
> macros {
> prkacl = CRYPTO=NONE, UPDATE=$PIN, DELETE=$PIN, GENERATE=NONE;
> }
> }
> [...]
> EF template-private-key {
> [...]
> acl = $prkacl;
> }
>
> So now I can use
> $ pkcs15-init --profile pkcs15+default+insecure -G rsa/2048 --insecure
> -l "key usable without PIN"
>
> It's a bit ugly, but makes the user think twice before generating an
> insecure key :)
>
> I still think that --insecure should "translate" $PIN to NONE, but
> that's another story.
>
> BYtE,
> Diego.
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
--
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
