Axel & Kent,
Thank you for your replies.
Your replies made me realize that individual apps/users should have control
over the keys they own, not the TPM administrator.
However, right now, even if a key has authUsage = 1, anyone can still delete
the key without any problem. So I can delete every key in system.data,
including SRK, even if authUsage = 1. Has anyone encountered this before?
Is this a bug?
Should the TSS stack prompt user for auth if the key's authUsage = 1 when
someone tries to unregister the key?
On 6/1/06, Axel Heider <axelheider@...> wrote:
> > The following question originated from trousers-users,
> > but I think it's more related to trousers-tech, so
> > sorry for mailing both lists.
> > The question is: since Tspi_Context_UnregisterKey
> > doesn't require any authorization, any user can write
> > a simple program to delete all the keys on a system.
> > This will cause a denial-of-service attack. Shouldn't
> > it require authorization?
> The point it, that this will not really solve the
> problem. In general, the persistent storage function
> offered by the TSS it a nice function, but....where
> is the storage? In fact, all TSS implementation keep
> it in a file and rely on the OS to protect this file.
> The TPM is not *NOT* use here and cannot be used
> because it does not have enought memory.
> So if the file is deleted, the keys are lost.
> What is missing here is a bottom-side interface that
> the TSS uses to access a really secure but customizable
> persistent storage - like a smart card, USB Token or
> even a server in the network. Unfortunatly this is not
> defined in the TSS spec. There has bee a discussion
> about this and the bottom line is, that you should not
> use these storage functions if you are really concerned
> about security. Manage the keys in your application or
> make the application use an interface like PKCS#11 to
> load the keys from a really secure storage. Then you can
> temporary store them in the persistent storage offered
> by the TSS for convenience - but you should not rely
> on it.
> Thinking about the problem, a simple solution for the
> current situation could be a service that runs in the
> background and imports and exports keys to the TSS
> storage. This way the application only needs to know
> the TSS API to work with keys, while the service in the
> background handles the current user's smart cards.
> This is not perfect or nice, but it could work and be
> even quite convenient is the background service is smart
> enough to load keys automatically.
> mfg Axel Heider
> Civilization is just a temporary failure of entropy.