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] C_RenameToken

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

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