Re: [Trustedjava-support] Locality- and PCR-based access control for NV RAM

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

On 2011-08-26 20:03, Jonathan McCune wrote:
> Greetings,

Hi,

> Let's suppose I want some NV space defined where the only access
> control mechanisms I care about are PCR values and Locality.  I can do
> something like this:
>
> jtt nv_definespace --index 0x00011222 --size 64 -p 10 -w --permission
> 0x00000000 --writelocality 0,1,2,3
>
> However, when I try to write to this new space, I get an error.
>
> jtt nv_write --file /tmp/64bytes --index 0x00011222
>
> additional info: illegal permissions - should not happen
>
>          at iaik.tc.tss.impl.java.tsp.TcNvRam.writeValue(TcNvRam.java:371)
>
> Looking at jTSS_0.6/src/jtss_tsp/src/iaik/tc/tss/impl/java/tsp/TcNvRam.java,
> we see that this exception is thrown by the last else in a tree of
> if-else statements that look at the value returned by:
> nvDataPub.getPermission().getAttributes().  In other words, this looks
> like intentional, fail-safe programming.

Yes, but unfortunately there is one "else if" statement (no write permission set 
and restricted by locality) missing, and that would have to throw a TSS_E_NOTIMPL.

The problem is that jTSS doesn't support unauthenticated commands.
A NV index which was defined as above would require an unauthenticated 
TPM_NV_WriteValue command. The error message in this case needs to be clarified.

> My real question then becomes, what's the problem?  Nothing stops me
> from defining an NV space and using the "auth method" to control
> access to it, and using a "well-known secret" for that auth value, but
> that seems silly.

That would be a possible work around for this scenario.

> Thus, I'm wondering if jTSS is being overly restrictive, or if I've
> missed some other rationale for this design choice.  Any insight would
> be much appreciated.

See above.

> Many Thanks,
> -Jon

Best regards,
Michael