trustedjava-support

[Trustedjava-support] TPM_NV_INDEX_TRIAL - wrong value

[Michael S. <ms...@nt...>]

Hi --

For some reason, TcTpmConstants.TPM_NV_INDEX_TRIAL has the "D" bit 
set.    This is probably a bug.

I used the constant in TcINvRam.defineSpace (in TcTpmNvData) to see if I 
had space to create a 100 octet space.  What I ended up with was a 
permanent 100 octet space that I can't get rid of.

When I use the correct value - 0xF004 - as the index, I get the 
anticipated behavior.  A "success" results in a return with no creation.

I'd review all of the TPM_NV_INDEX_* values and make sure you're using 
the correct values.

Mike

Re: [Trustedjava-support] TPM_NV_INDEX_TRIAL - wrong value

[Ronald T. <ron...@ia...>]

Hi Michael,

Thank you for pointing this out. We will take a look at this issue but 
it might take some time..

Ronald

On 05/14/2012 07:31 PM, Michael StJohns wrote:
> Hi --
>
> For some reason, TcTpmConstants.TPM_NV_INDEX_TRIAL has the "D" bit
> set.    This is probably a bug.
>
> I used the constant in TcINvRam.defineSpace (in TcTpmNvData) to see if I
> had space to create a 100 octet space.  What I ended up with was a
> permanent 100 octet space that I can't get rid of.
>
> When I use the correct value - 0xF004 - as the index, I get the
> anticipated behavior.  A "success" results in a return with no creation.
>
> I'd review all of the TPM_NV_INDEX_* values and make sure you're using
> the correct values.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Trustedjava-support mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedjava-support


-- 
Dipl.-Ing. Ronald Tögl          phone +43 316/873-5502
Secure and Correct Systems      fax   +43 316/873-5520
IAIK                            ron...@ia...
Graz University of Technology   http://www.iaik.tugraz.at

Re: [Trustedjava-support] TPM_NV_INDEX_TRIAL - wrong value

[Michael G. <m.g...@tu...>]

On 05/14/2012 07:31 PM, Michael StJohns wrote:
> Hi --

Hi Michael,

> For some reason, TcTpmConstants.TPM_NV_INDEX_TRIAL has the "D" bit
> set.    This is probably a bug.

I agree that this is not the best value for this constant. It will be 
changed to 0x0000f004 in a future release. Anyhow please note that it's 
a valid index according to the specification.

> I used the constant in TcINvRam.defineSpace (in TcTpmNvData) to see if I
> had space to create a 100 octet space.  What I ended up with was a
> permanent 100 octet space that I can't get rid of.

What exactly do you mean by 'can't get rid of'? According to the TPM 
specification this should not happen. When you try to define an index 
with the D-bit set, a shipped TPM should return TPM_BADINDEX. Which TPM 
do you use? Is the TPM's nvLocked bit set to true? If it is not, then 
D-bit indices can be defined, but also deleted.

Can you please provide the output of the following commands?

jtt tpm_version
jtt tpm_flags
jtt nv_decode --index 0x1000f004

> When I use the correct value - 0xF004 - as the index, I get the
> anticipated behavior.  A "success" results in a return with no creation.

That's what I would have expected ;)

> I'd review all of the TPM_NV_INDEX_* values and make sure you're using
> the correct values.

Both versions with and without D-bit set are correct. For compatibility 
reasons the other constants will remain unchanged.

> Mike

HTH,
Michael

Re: [Trustedjava-support] TPM_NV_INDEX_TRIAL - wrong value

[Michael S. <ms...@nt...>]

After a long break, I'm finally getting back to this, and with a 
different set of TPMs.

I've got an STM TPM on my Lenovo T530 (as opposed to the intel one I had 
on the T510).  I've got an ATMEL TPM on a server machine with a TPM 
daughter card.

It turns out that the TPM daughter card with the ATMEL TPM does not have 
the nvLocked bit set.  I found this out when I was trying to use the 
TPM_NV_INDEX_TRIAL  index to check space availability, which instead 
ended up actually creating stuff.  I tried both the 0xf004 and 
0x1000f004 indexes and both ended up creating NV space.  I was easily 
able to delete the 0xf004 stuff, but I kept getting an error when I 
tried to delete the 0x1000f004 item.  This turned out to be a problem in 
/jTSS_0.7a/src/jtss_tsp/src/iaik/tc/tss/impl/java/tsp/TcNvRam.java 
around line 261. The code checks to see if you're trying to delete an 
index with the D bit set and throws an error, rather than attempting to 
do the delete and passing on the TPM originated error.

What I think you probably wanted to do here is do a try/catch block 
around the low-level call, and if there is an error, change the error 
cause message on the caught exception and continue the throw.  
Basically, explain the error if it happens, rather than anticipating it.

e.g.

try {
     TcTspInternal.TspNvDefineSpace_Internal(context_, pubData, encAuth, 
inAuth1, ownerAuth);
} catch (TcTssException ex) {
     if (ex.getErrCode() == TPM_E_BADINDEX) {
          if ((nvIndex_ & TcTssConstants.TSS_NV_DEFINED) != 0) {
                 ex.setMessage("index with set-defined bit is not allowed");
           }
     }
     throw ex;
}

I know there isn't a setMessage method for TcTssException, but you 
should either have that or the normal exception "new 
<exception>(Throwable cause)" constructor.

For my work around, I commented out the block and was able to delete 
both rogue indexes.



The second problem I encountered was in the same code.  I attempted to 
lock the NVRam by defining space of size 0 at index 0xffffffff so I 
wouldn't encounter further problems. Unfortunately, that failed with a 
Null pointer error which I traced to line 88 of TcNvRam.  You pass in a 
null pointer for the iAuth argument and later routines blow up because 
of it.    I haven't yet tried the simple work around of commenting out 
this "if" block, but it's probable that 
TcTspInternal.TspNvDefineSpace_Internal needs some revision to catch 
null arguments and handle them properly.


Thanks - Mike





On 7/9/2012 10:55 AM, Michael Gissing wrote:
> On 05/14/2012 07:31 PM, Michael StJohns wrote:
>> Hi --
>
> Hi Michael,
>
>> For some reason, TcTpmConstants.TPM_NV_INDEX_TRIAL has the "D" bit
>> set.    This is probably a bug.
>
> I agree that this is not the best value for this constant. It will be 
> changed to 0x0000f004 in a future release. Anyhow please note that 
> it's a valid index according to the specification.
>
>> I used the constant in TcINvRam.defineSpace (in TcTpmNvData) to see if I
>> had space to create a 100 octet space.  What I ended up with was a
>> permanent 100 octet space that I can't get rid of.
>
> What exactly do you mean by 'can't get rid of'? According to the TPM 
> specification this should not happen. When you try to define an index 
> with the D-bit set, a shipped TPM should return TPM_BADINDEX. Which 
> TPM do you use? Is the TPM's nvLocked bit set to true? If it is not, 
> then D-bit indices can be defined, but also deleted.
>
> Can you please provide the output of the following commands?
>
> jtt tpm_version
> jtt tpm_flags
> jtt nv_decode --index 0x1000f004
>
>> When I use the correct value - 0xF004 - as the index, I get the
>> anticipated behavior.  A "success" results in a return with no creation.
>
> That's what I would have expected ;)
>
>> I'd review all of the TPM_NV_INDEX_* values and make sure you're using
>> the correct values.
>
> Both versions with and without D-bit set are correct. For 
> compatibility reasons the other constants will remain unchanged.
>
>> Mike
>
> HTH,
> Michael

Re: [Trustedjava-support] TPM_NV_INDEX_TRIAL - wrong value

[Michael S. <ms...@nt...>]

On 2/17/2013 10:11 PM, Michael StJohns wrote:
> The second problem I encountered was in the same code.  I attempted to 
> lock the NVRam by defining space of size 0 at index 0xffffffff so I 
> wouldn't encounter further problems. Unfortunately, that failed with a 
> Null pointer error which I traced to line 88 of TcNvRam.  You pass in 
> a null pointer for the iAuth argument and later routines blow up 
> because of it.    I haven't yet tried the simple work around of 
> commenting out this "if" block, but it's probable that 
> TcTspInternal.TspNvDefineSpace_Internal needs some revision to catch 
> null arguments and handle them properly.

This appears to be specific to the SOAP binding.  TcTcsBindingSoap fails 
at line 2532 due to the null value for inAuth1.  So there's an argument 
encoding issue for SOAP.

Mike