Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
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
Re: [opensc-devel] FOSS development
On Sun, May 27, 2012 at 11:59 PM, Peter Stuge wrote: > Jean-Michel Pouré - GOOZE wrote: > > What I suggest is that OpenSC should be hosted on GIThub with write > > access to core developers (at least 5/6 people). > > Insisting on changing some hosting situation that has been set up is > nothing but obnoxious protesting and spitting on the already > established hosting. > Peter, probably it useless, but may I bring once more to your attention the fact that github is set into the center for Development Policy by Martin himself. Look onto the diagram in https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy . Centering development around github.com brings no benefits whatsoever > over opensc-project.org. The latter allows the project to do nice > integration and customization of all tools. Github not so much. > What integration do you mean? On opensc-project.org the tarball, MSI and DMG are built. No RPMs, DEB, no automated tests, ... 'Customization of all tools' -- what tools do you mean ? Effectively, it would be nice to build and publish Linux packages, connect automated tests, include other OpenSC sub-projects, ... But who will do all this on opensc-project.org? Martin have no time, no one else can/allowed to do something. Beside the necessity of the perfect commits, can you propose something else? Kind regards, Viktor. > //Peter > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
On Monday, May 28 at 01:34PM, Peter Marschall wrote: > > Hi PEter, > > thanks for your answer. > > On Monday, 28. May 2012, Peter Koch wrote: > > Have a look at "Security Attributes" in ISO 7816-4 and table > > "Access mode byte for EFs". > > Unfortunately I do not have access to that either. > > But you have me more hints to search the web. There are several drafts and previews of 7816-4 available on the web: http://lmgtfy.com/?q=iso7816-4 -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACEhttp://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc pgp5tjuJpZR0E.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Hi, On Monday, 28. May 2012, Martin Paljak wrote: > > If it works (even in a limited/restricted way), it is better than not > > having any support at all. > > Sure. If this can be accomplished without changing the underlying > mechanics/assumptions, perfect. That's what we try to achieve with openPGP. > I'm just trying to point out that it could be useful and more > straightforward to change some of the assumptions in OpenSC, like the > fact that there *must* be a filesystem or that key-generation *must* > go through pkcs#15 data structure generation layer. Hmmm, the issue I see here is that someone with enough knowledge of opensc and all the relevant standards needs to write the code. This code needs either be compliant with the current situation or require a complete rewrite of opensc (with potential destabilization, ...). All this takes time, and I fear noone matching the description above has enough time to do that. So , this is surely not a goal reachable in short term. What about the following compromise / approach: Quân & I try to continue our path with OpenPGP and the current opensc infrastructure. If someone writes the infrastructure for the other option, we will happily migrate the openpgp driver (as it should simplify the driver). Best regards PEter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
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 -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
Hello, On Mon, May 28, 2012 at 11:10 AM, Peter Marschall wrote: > I am trying to extend openpgp-tool to load data to the various writable DOs, > and - if possible - I want it to determine automatically the permissions of > the (emulated) files using standard interfaces, i.e. security attributes or > preferably ACLs. As the file system on openPGP cards only is emulated using > opensc, I need to emulate these data structures too. I don't quite get it. IMHO ACLs would matter, if you would have actual files, and the ACL-s would actually be communicated to/from the card by some means. I don't really understand how you would use ACL-s with the "gender" field, for example. From OpenPGP spec v201: 5 Security Architecture All commands and data of a smart card are under control of the security of the card oper ating system. ISO defines mechanisms, attributes (e.g. in FCP) and environments for security purposes. Because this features are quite complex and may differ from card to card (depending on mask developer), the OpenPGP application does not evaluate security related items of a card. So this chapter is informative for the card developer and defines the access conditions for all commands and data objects of the application in a common way. The described security features are mandatory for the card, but the coding or the way of implementation is up to the card developer, manufacturer or personaliser. Maybe I'm missing something... Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Hello,
On Sun, May 27, 2012 at 11:18 PM, Peter Marschall wrote:
> Hi,
>
> On Friday, 25. May 2012, Martin Paljak wrote:
>
>> In the long run, I don't think that it helps to emulate a filesystem
>> on top of non-filesystem cards (like OpenPGP or Muscle). Or to try to
>> make it fit into the filesystem-oriented stack of OpenSC.
> Why?
> If it works (even in a limited/restricted way), it is better than not having
> any support at all.
Sure. If this can be accomplished without changing the underlying
mechanics/assumptions, perfect.
I'm just trying to point out that it could be useful and more
straightforward to change some of the assumptions in OpenSC, like the
fact that there *must* be a filesystem or that key-generation *must*
go through pkcs#15 data structure generation layer.
>> It is nice to be able to poke around with opensc-explorer, but the
>> notion of a file and a path should mean that the file is actually
>> selectable with ISO SELECT command. Which is not true (a plain APDU,
>> outside of the libopensc emulation layer, would fail).
> I do not understand that argument, especially if we're talking about
> an emulation within the opensc software stack.
> Why should it matter that the emulation does not exist outside opensc?
> When it works (even only partiallly) with opensc, it works.
> When it does not work with opensc it works nowhere.
This not a problem for OpenPGP, really, as nothing is written to the
card that would actually contain the fake paths. But more of a problem
of Muscle applet (that does pump PKCS#15 data back to the card)
The common (related) traits are:
- emulating a filesystem that doesn't actually exist (OK if the
emulation is only present to "please" existing OpenSC design)
- wanting to "write something" to the card, with pkcs15-init, even if
that's probably not the best option (as no PKCS#15 ASN.1 is
generated/written)
Which brings the two thoughts:
- emulating a filesystem should not be a requirement if possible, as
it leaves a false assumption to some users (who expect a file to also
be present on the card). But of course, it is a nice to have feature
(opensc-explorer etc).
- re-generating/importing keys and re-loading certificates must not
be made under the "pkcs15init" section, as this may not result in
PKCS#15 related updates in the card.
So, instead of requiring an additional mapper in src/pkcs15init, I'd
propose to extend the pkcs15-ish API in src/libopensc to include
"generate object" and/or "put object" calls, to (re-)generate keys,
import keys and reload certificates.
Something like:
sc_pkcs15_change_object(card, object_type, object_id, new_object, flags)
and related callback in sc_pkcs15_operations.
Which could be implemented entirely in src/libopensc/(card/pkcs15) name.c
>> In case of OpenPGP, where no files or PKCS#15 data structures are
>> written to the card (the card already has a fixed profile, with fixed
>> data slots), it makes no sense. The main utility of pkcs15-init is
>> creating (and storing) PKCS#15 ASN.1 structures to the card, when such
>> slots for keys or certificates are created as a side-product. If ASN.
>> shall not be created, pcks15-init should IMHO not be used.
> Well, pkcs15-init might not be the tool suitable for the job.
> But please, let Quân continue trying - maybe he can make the emulation work.
That's not my intention, of course :)
> If his approach ("try to make the emulation so good that it allows using the
> standard tools") does not work out, extending the new openpgp-tool to do what
> he wants, should be even easier.
Probably. Some operations (like setting the account names and other
data objects) do not fit nicely anywhere else.
Martin
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] FOSS development
> Insisting on changing some hosting situation that has been set up is > nothing but obnoxious protesting and spitting on the already > established hosting. Peter, do you mean that moving OpenSC to GIThub and opening administration to a group of core developers would be "obnoxious" and "spitting" on established hosting. Can you elaborate on that and be more precise? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
Hi PEter, thanks for your answer. On Monday, 28. May 2012, Peter Koch wrote: > Have a look at "Security Attributes" in ISO 7816-4 and table > "Access mode byte for EFs". Unfortunately I do not have access to that either. But you have me more hints to search the web. > You may either use compact or expanded form to describe your access rules. > When those DOs are selected I would return a FCP with tag A0 > which should contan two access mode bytes (one for reading > and one for writing) each followed by security condition bytes. Best PEter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
Hi Peter I am trying to extend openpgp-tool to load data to the various writable DOs, > and - if possible - I want it to determine automatically the permissions of > the (emulated) files using standard interfaces, i.e. security attributes or > preferably ACLs. As the file system on openPGP cards only is emulated using > opensc, I need to emulate these data structures too. > > I searched the net, but did not get anything that that really helped (I > guess, > I did not know/ use the correct search terms ;-) > > I found that ISO 7816-9 should contain info on security attributes, but I > am > not really keen on paying ~€60 for this information alone. > Have a look at "Security Attributes" in ISO 7816-4 and table "Access mode byte for EFs". You may either use compact or expanded form to describe your access rules. When those DOs are selected I would return a FCP with tag A0 which should contan two access mode bytes (one for reading and one for writing) each followed by security condition bytes. Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Docs/Specs on ACLs / security attributes?
Hi, I am trying to extend openpgp-tool to load data to the various writable DOs, and - if possible - I want it to determine automatically the permissions of the (emulated) files using standard interfaces, i.e. security attributes or preferably ACLs. As the file system on openPGP cards only is emulated using opensc, I need to emulate these data structures too. I searched the net, but did not get anything that that really helped (I guess, I did not know/ use the correct search terms ;-) I found that ISO 7816-9 should contain info on security attributes, but I am not really keen on paying ~€60 for this information alone. Unfortunately I did not find anything on ACLs on EFs/DFs (Google only gave me tons of info an ACLs in Windows ;-) Does anyone have documentation or specs on ACLs (preferred) or security attributes. Thanks in advance PETer -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
