Re: [pkcs11] User types - discussion thread

[Michael StJohns <msj@nthpermutation.com>]

Related to the user types discussion and to key protection and to a 
bunch of other things is what a user (vs role) model might look like.  
Some of the following is based on my experience with the Utimaco line of 
HSMs and how they do and use strong authentication.     As a side note, 
Utimaco provides a free HSM simulator that exactly mimics their hardware 
product and the documentation provided with the simulator is the same 
documentation used for the HSM.  If you want more details on what I'm 
discussing here - that's a good place to go look.


UT uses the normal pin login as the "finish" operation for logging in to 
a token.  It can be preceded by any number of "strong" logins.

UT uses the concept of a "login state" consisting of 8 uint4's packed 
into a single 32 bit word.   A normal login (e.g. pin based login) 
contributes a 00000000 login state value.   A strong auth user 
contributes whatever login state value is set for the user - basically 
any of the 8 uint4s can be set to 0-2.  So if I have one user with a 
state vector of 00000001 and another with a state vector of 00000010, if 
both login the login state for the session is 00000011.

UT tags the token (not the individual keys) with the option to require 
strong authentication.  The token has an attribute that's settable 
through a well-known handle to a required login state (which is 
represented similar to the above).  Say you want the token to require at 
least one strong auth - so you set the required strong auth login state 
value to 00000001.  The login state of the token is compared to the 
required value (each uint4 in the login state to each matching uint4 in 
the required value) and if the login state is equal to or superset of 
the required value, the login succeeds and the token may be used.


This construct is used to implement M of N systems.  Say for example I 
want require that both QA and Firmware sign off on the use of the token 
(for example to sign firmware).  I assign users in the firmware groups a 
login value of 00000001, and the users in the QA group a login value of 
00000010.   I assign the token a use value of 00000011.  So this 
requires at least one user from QA and one user from Firmware to login 
before the token can be used.

Alternately, I can implement a 3 of N system by setting the token use 
value to something like 00003000 and then assigning users the 
appropriate login values.  I can give certain users more privileges 
(e.g. bosses) by assigning them higher values in specific uint4 nibbles 
or by assigning them values in multiple buckets.

We (the company I work with)  have found over time that the 8 nibble 
construct is probably too few buckets for a truly flexible system, but 
it's worked pretty well for the applications we've built.  If PKCS11 
wants to use something like this I might suggest an expandable approach 
for the state and use vectors where the vectors are arrays of uint8 
values instead of being stored as 32bit words.

Leaving aside for a minute the question of how exactly strong 
authentication is done, let's consider how something like this could be 
used on a per-object basis.

I would probably mark each object with a use vector - and if the use 
vector isn't present,  the object can be used without strong 
authentication.  If the vector is present, the login state must be equal 
to or greater the use vector to use the object

I would probably also mark each object with an admin vector - that 
vector would control things like whether or not the key could be 
deleted, copied or modified.    It may actually make sense to mark each 
individual admin function with a vector - so that you could allow one 
admin to delete or export the object, but not change its privileges.  
This would require some more thought than I'm prepared to do right at 
this minute.


I like the UT approach because its pretty clean to implement and to 
understand how to get specific behaviors.    The user administration 
process UT uses is outside of the PKCS11 scope, but I think it would be 
possible to actually create a PKCS11 user admin model based on the 
PKCS11 object model that would work quite well.

Thoughts? Mike