Hal Finney wrote:
> In other words, the TPM is born in a state in which authorization is
> not enforced for NV commands. That is the state your (and my) TPM is
> in now. It is why you were able to create NV areas without using owner
> The idea is that soon after you receive your TPM, you do (or maybe the
> manufacturer does) DefineSpace with the special index of
> TPM_NV_INDEX_LOCK (or TSS_NV_INDEX_LOCK from Trousers). This will
> cause NV permissions to start being enforced. Among other advantages,
> it will make it harder for malicious software to harm your TPM by
> wearing out its NV area with repeated writes. However, it is (pretty
> much) an irreversible operation. Once you enable authorization, it
> will stay on forever. There's no particular down side to this except
> that it may make it harder for you to help inexperienced people who
> run into this problem, since you won't be able to reproduce the
> conditions they have.
> However, I do think it is a mistake for the TPMs not to allow space to
> be deleted when in this state, and to return the TPM_BAD_DATASIZE
> error. Having said that, the description is pretty complicated on what
> the TPM is supposed to do while in this state, to handle the
> TPM_NV_DefineSpace command (which is also used to release space). It
> basically says that most authorization checks should be ignored in
> this state, including the one in Action 5c, but not the ones in Action
> 6f or Action 9f. Lots of legalese. Now it appears to me that the error
> is happening because of Action 5c, which is supposed to be ignored, so
> I think the TPM manufacturers somehow screwed this one up.
> Maybe it is intentional though, since the point of the nvLocked bit is
> to allow manufacturers to define NV storage space and put data into it
> that users will find useful later. Maybe they were worried that users
> would accidentally delete something crucial (as indeed your test
> program tries to do if run with the -d flag) so maybe they broke the
> rules intentionally and made it so that even before nvLocked is set,
> deleting NV areas will require owner authorization.
> But the bottom line is that in the state the TPM is intended to be
> used in, with nvLocked having been cleared via defining space with the
> TPM_NV_INDEX_LOCK index, owner auth will be needed both to create and
> delete NV storage areas. I haven't taken this step yet, but I probably
> will soon. Presumably everything will work OK in that state.
> Hal Finney
Thanks for the detailed response.
What if no one has called DefineSpace with TPM_NV_INDEX_LOCK ? If it is
not locked, and the space was not created with owner auth, why can't I
it (with or without the owner auth) ? The situation is such that if I
do not set
the owner-auth, I get TPM_BAD_DATASIZE,if I do set owner-auth, I get
"authentication failed". It seems I am stuck and cannot clear this NV
without resetting the TPM.