Hi Peter,
Does this
pgp2_objects[] = { /* OpenPGP card spec 2.0 */
{ 0x004d, CONSTRUCTED, READ_NEVER | WRITE_PIN3,
NULL, sc_put_data },
{ 0x004f, SIMPLE, READ_ALWAYS | WRITE_NEVER,
sc_get_data, NULL },
{ 0x005b, SIMPLE, READ_ALWAYS | WRITE_PIN3,
NULL, sc_put_data },
{ 0x005e, SIMPLE, READ_ALWAYS | WRITE_PIN3,
sc_get_data, sc_put_data },
help?
We will translate from these access permission to ACL.
For example, the ACL for 005e file is:
sc_file_add_acl_entry(file, SC_AC_OP_WRITE, SC_AC_CHV, 0x83);
sc_file_add_acl_entry(file, SC_AC_OP_UPDATE, SC_AC_CHV, 0x83);
sc_file_add_acl_entry(file, SC_AC_OP_DELETE, SC_AC_CHV, 0x83);
sc_file_add_acl_entry(file, SC_AC_OP_CREATE, SC_AC_CHV, 0x83);
(0x83 is key reference of Admin PIN)
On 05/28/2012 09:31 PM, Peter Marschall wrote:
> Hi,
>
> On Monday, 28. May 2012, Martin Paljak wrote:
>> I don't really understand how you would use ACL-s with the "gender"
>> field, for example.
> Let me try to explain what I want to achieve.
>
> card-openpgp.c emulates a filesystem for the DOs on the card.
>
> Now, some of the DOs are
> * readable after VERIFY PIN2
> some are
> * writeable a VERIFY PIN2
> some are
> * writeable after VERIFY PIN3
> ...
> (and the sets may overlap)
>
> All this information is written in the spec only, and thus is implicit.
> (i.e. the DO do not tell about their permissions)
>
> This "implicit only" behaviour does not necessarily extend to the
> emulated file system.
> (i.e. the emulated files can have emulated ACLs, ... that can be
> evaluated by tools)
>
> My goal is to extend openpgp-tool in a way that it does not need
> implicit information on the readability/writeablity of the DOs, but
> can use standard-compliant data to get the information.
> This way the mapping only needs to be done in card-openpgp.c only
> instead of distributed over many places.
>
> Let me try to show it graphically
>
> On the Card
> DO 0101
> permissions (implicit from the spec)
> read: always
> write: VERIFY PIN2
> |
> | (this happens in card-openpgp.c)
> |
> v
> Emulated File System
> EF 0101
> ACL: READ=always, WRITE=VERIFY CHV2
>
> Currently the ACLs are not emulated yet.
> But If they are, then standard-compliant applications can determine
> what needs to be done in order to be able to e.g. write to an emulated EF.
>
> So, the ACLs shall not in any way try to influnce what happens on the card (I
> am very crealy aware that they can't), but tell to the outside world how the
> permissions are laid out on an OpenPGP card.
> This way not every application needs to know the specs of an OpenPGP
> card, but can use the information provided by the emulation.
>
> I hope that makes my goals clearer.
>
> If this is not doable with either security attributes or/and ACLs, because
> their intention and potential use cases conflict with that goal, please tell.
>
> Best regards
> Peter
>
--
Regards,
Quân
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
