ACL types for the PINs

[Viktor TARASOV-2]

Hi,

I would like to update the support of the Oberthur card
and to implement the PIN unblocking style of the Oberthur's native
middleware.

For the Oberthur card a PIN is some internal object (it's not like a SDO
object)
and the ACLs for the PIN operations ('RESET', 'CHANGE' and 'DEFINE')
are included into the ACLs of the parent DF.

So, my question is.
Will it be acceptable to introduce some new SC_AC_OP_ types
to make possible the control of these ACLs by the card profile?

As far as I see, it should not harm the other card drivers.

Kind wishes,
Viktor Tarasov.

--
Viktor Tarasov <viktor.tarasov@...>

_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Andreas Jellinghaus-2]

Am Dienstag 03 November 2009 13:41:07 schrieb Viktor TARASOV:

> Hi,
>
> I would like to update the support of the Oberthur card
> and to implement the PIN unblocking style of the Oberthur's native
> middleware.
>
> For the Oberthur card a PIN is some internal object (it's not like a SDO
> object)
> and the ACLs for the PIN operations ('RESET', 'CHANGE' and 'DEFINE')
> are included into the ACLs of the parent DF.
>
> So, my question is.
> Will it be acceptable to introduce some new SC_AC_OP_ types
> to make possible the control of these ACLs by the card profile?

sorry, not much clue here how opensc works with acls.

when you create / set ACL on a DF, you need to know both the
settings for the DF itself, as well for embedded objects?
so you need extra flags passed down the chain to handle those?

or can you create the DF firsth with conserative settings,
and have a second funciton call to update it to set the
values for the embedded objects?

how do other cards work? I guess the df is created with
df acl passed to it, and the pin is created with pin acl
passed down the function chain?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Viktor TARASOV-2]

Andreas Jellinghaus wrote:

> Am Dienstag 03 November 2009 13:41:07 schrieb Viktor TARASOV:
>  
>> Hi,
>>
>> I would like to update the support of the Oberthur card
>> and to implement the PIN unblocking style of the Oberthur's native
>> middleware.
>>
>> For the Oberthur card a PIN is some internal object (it's not like a SDO
>> object)
>> and the ACLs for the PIN operations ('RESET', 'CHANGE' and 'DEFINE')
>> are included into the ACLs of the parent DF.
>>
>> So, my question is.
>> Will it be acceptable to introduce some new SC_AC_OP_ types
>> to make possible the control of these ACLs by the card profile?
>>    
>
> sorry, not much clue here how opensc works with acls.
>  

'Select file' returns (can return) the FCI or FCP data with the ACL
bytes included.
For the ACL bytes the different kinds of encoding are used.

For example for the Oberthur-IdOne-AuthentIC it's always 8 bytes:
the byte position and file type define the type of the protected operation.

Another example, SDO style: here the ACLs is one or more of groups
composed from the 'usage' byte and 'security condition' bytes.
Somewhere, it's like encoding of the interface bytes in the ATR .

So, at the file selection OpenSC card driver fills up the 'acl' entry in
the 'sc_file' structure.
Then, the interested OpenSC part tries to satisfy security condition
before the starting of the particular operation.
Mostly it's the pkcs15init part that uses for that
sc_pkcs15init_authenticate() procedure.
For example, to delete some file the pkcs15init part firstly tries to
satisfy the SC_AC_OP_DELETE acl condition of the file (for
Oberthur-IdOne-AuthentIC card the acl of the parent DF).
sc_pkcs15init_authenticate() gets the file's acls, analyze the
protection type, checks if there are some callback functions defined for
the PIN/KEY verification and finally calls (if asked) the sc_verify().

In our 'internal' OpenSC version we are also checking the acls at the
card driver level -- to detect the 'SM' or 'External Authentication'.

> when you create / set ACL on a DF, you need to know both the
> settings for the DF itself, as well for embedded objects?
> so you need extra flags passed down the chain to handle those?
>  
Generally not.
The ACLs of the parent DF and the ones of the embedded objects are
completely independents (IMHO).
But there some 'special' case(s).
Only now I realize that 'Oberthur AuthentIC IdOne' is one of them. It
concerns the PINs but also the embedded files.


For the other cards a PIN is some special type of SDO (Oberthur's
IdOne-Classic, Gemalto 'TOP IM ..', IAS),
or some intrinsic PIN object created while instantiating the dedicated
applet (Gemalto Access).
In these two cases you can get the PIN attributes (and PIN's ACLs) by
'GET DATA' for SDO, or some 'get_pin_policy'. The parent DF has no
'DELETE' or other power on the embedded files.


It's different with the 'Oberthur AuthentIC IdOne'.
As for PIN, there is a special command to create PIN, but after that,
you cannot get any information about it.
Situation is 'corrected' be the fact the parent DF has some additional
power on the embedded files and PINs.
It's in the ACLs of the parent DF is defined the security condition for
the file deleting and for the PIN operations .

So, for Oberthur card the answer is 'yes' -- to create DF some
additional information about the future embedded objects is needed.
That's what about my initial question was.


> or can you create the DF firsth with conserative settings,
> and have a second funciton call to update it to set the
> values for the embedded objects?
>  
No, once DF is created you cannot change the security conditions.
Untill now, it was true for all the cards that I've crossed.

> how do other cards work? I guess the df is created with
> df acl passed to it, and the pin is created with pin acl
> passed down the function chain?
>
> Regards, Andreas
>  

Regards,
Viktor.



--
Viktor Tarasov <viktor.tarasov@...>

_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel