Re: [pkcs11] C_RenameToken

[Michael StJohns <msj@nthpermutation.com>]

On 6/7/2013 4:11 PM, Dina Kurktchi wrote:
> My thought about renaming tokens is that it would be normal user
> function, not an SO function, though nothing should preclude an
> SO from using the function too.  Our company's implementation
> of a software token is SO-less.  I'd have to be my own SO for
> my software token, so we figured why bother with an SO at all.
> The spec does allow for token initialization outside of Cryptoki,
> so we took advantage of that.  (It may or may not stay that way.)
>
> The SO's 'lifetime' of usefulness to the normal user is short:
> (1) initialize tokens, including the initial token name, and
> (2) set initial PINs.
> After that, most of time, the SO doesn't really do much more
> for normal users.  Yes, if users need tokens reinitialized,
> or some public objects need tending, the SO is there for that.
>
> Normal users change token PINs without SO intervention, so why
> shouldn't he be able to change his token's name? 

The initial setting of the label is done through C_InitToken, which is 
sort of by definition an SO or pre-SO activity.

Normal users change their own PINs without SO intervention, they don't 
change the SO's pin.

Thinking about this, I see a possible attack where a user changes the 
name of his token, substitutes it for someone else's token. That someone 
else, thinking that they've just forgotten their PIN, get the SO to 
change their PIN for them.  Now the someone else is using the wrong set 
of keys.    I don't know that that is a viable attack, but I think I'd 
rather limit the token name change to the SO that issued the token.

Later, Mike