OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pkcs11] User types - discussion thread

On 10/25/2013 1:16 PM, Chris Zimman wrote:
Hi Mike

Yes, we manage the users through an external mechanism.  As you're aware, PKCS11 doesn't really have the notion of add/delete/change privs in the existing API.  I wanted to preserve compatability.

OK. I may try and define a CKO_USER_CREDENTIALS object - I think that may work for doing things similar to what you do.

The structure is passed as a void * to the PIN argument and sizeof(CK_EXTENDED_LOGIN) for the length argument.

That's what I thought. Unfortunately, that won't work well with the Java PKCS11 implementation due to strong typing. Void pointers are to be avoided. :-)

In my implementation, there is a table/attribute driven state machine that allows you to define somewhat arbitrary rules for each type of C_* operation via callbacks.

typedef struct {
     CK_ATTRIBUTE_TYPE   attr_type;
     CK_BBOOL            	token_impl_specific;
     CK_RV               	(*set)(CK_ATTRIBUTE *);
     CK_RV               	(*validate)(CK_ATTRIBUTE *);
} bpkcs11_vendor_attr_list_item;

An example of how this is used looks something like this:

static bpkcs11_vendor_attr_list_item bpkcs11_vendor_attrs[] = {
     { CKA_OWNER_UUID,                   		CK_TRUE,        set_uuid,			validate_uuid		    },
     { CKA_ALLOWED_USE_TIME_START,       	CK_TRUE,        set_use_time_start,	validate_use_time_start  },
     { CKA_ALLOWED_USE_TIME_STOP,        	CK_TRUE,        set_use_time_stop 	validate_use_time_stop  },
     { CKA_EXPORT_SHARE_REQUIRED,     	CK_TRUE,        set_share_exp_req,	validate_share_exp_req  },
     { CKA_EXPORT_SHARE_REQUIRED_NUM,    	CK_TRUE,        set_share_exp_req_num, validate_share_exp_req_num },

The attributes are for things like checking an object owner via UUID, checking the time that an object is legal to use, or that to export an object requires a threshold.


-----Original Message-----
From: Michael StJohns [mailto:msj@nthpermutation.com]
Sent: Friday, October 25, 2013 12:07 PM
To: Chris Zimman; pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] User types - discussion thread

Hi Chris -

Could you comment a bit on how you do user management?  E.g.
adding/deleting/changing privileges for individual users?  Is this external to PKCS11 or done via something like the object creation/deletion process?

For the structure below - how is this passed?  Is it passed in via the PIN pointer? or did you come up with a different login command?

Lastly, how is the context data used by the rest of PKCS11?

Thanks - Mike

On 10/22/2013 2:21 PM, Chris Zimman wrote:
Hi Mike

I would agree with your comment around role based access control in terms of it being constricting.  For our needs, it just simply did not work.  To that end, we added CKU_EXTENDED_LOGIN:


/* Bloomberg extension for token login */
#define CKU_EXTENDED		3

typedef struct {
      CK_UTF8CHAR_PTR	*username;		/* User name */
      CK_ULONG		name_len;		/* Length of user name */
      CK_VOID_PTR	context;		/* Used to pass around token specific context data */
      CK_ULONG		context_size;		/* Size of context data */

#endif	/* defined(BPKCS11_EXTENDED_LOGIN) */

We have the extended attributes to do things that you mention, such as allow one user to create a key and provide fine grained access control to other users that can access the key.  You can extend this somewhat arbitrarily as well in terms of the access control policies (e.g. user X creates a key, shares with user Y, but says that user Y can only use the key M-F between 8AM - 5PM, etc.).


-----Original Message-----
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Michael StJohns
Sent: Sunday, October 13, 2013 4:34 PM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] User types - discussion thread

In PKCS11 there are currently two types of users, CKU_USER, CKU_SO and CKU_CONTEXT_SPECIFIC.  The USER type, when logged in, can access all the keys on the token, use them and change their attributes within the limits of PKCS11 policy.

The SO user type has only a single function defined in PKCS11 as far as I can tell  - marking keys as trusted.

The CONTEXT_SPECIFIC user seems to be used only for those keys that require authentication each time they're used.

The above provides only a minimal amount of role based policy protections.  Over the years I've found this minimal set of roles to be somewhat constricting in building PKCS11 applications as they don't provide granular enough control over the token.  We've added a few additional attributes (CKA_COPYABLE and CKA_DESTROYABLE) as of 2.40 that provide some improvements, but I think we should consider modifying the model either slightly or comprehensively:

Slightly:  One of the big issues I've encountered with PKCS11 is that
the creators of the key materials are not always the users of the key materials.  That leads to complications in managing the token in that we'd (e.g. my customers) *really* like to prevent the users of the key materials from either creating or destroying key material.
CKA_DESTROYABLE works for the destroying part, but there's no way to prevent the creation.  A slight modification to the above set of user types might be the addition of a CKU_SESSION_USER who's allowed read-only access to token key material for use, but can't create or destroy any CKA_TOKEN=true objects - the session user MAY create session key material as necessary.  A second slight modification might include the addition of a CKU_OWNER_USER who in addition to all the access a CKU_USER gets may set key protection attributes on the keys irrespective of normal policy (e.g. can violate the stickyness rules for
attributes).    So CKU_OWNER_USER > CKU_USER > CKU_SESSION_USER in terms
of access.

Comprehensive:  Another possible approach may be to go to a full user (vs role) based system where each object is tagged both with the owner (who gets to set attributes) and the users allowed to use the object.
There's probably also the concept of a token owner who gets add and delete users. Obviously, this would be a bit more disruptive than the
simple additions described above.    It would require a more
comprehensive user management system than currently exists, and a set of
functions to manage the access control lists for the objects.    But
this approach may be required to support multi-party (m of n) authorization models.

A third option is to standardize both - but make the "comprehensive"
version optional.



To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]