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

[Jonathan M. <jon...@cm...>]

Greetings,

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

(Including lower localities just so that jtt can continue to attempt
nv_read and nv_write commands from Linux; obviously the locality
enforcement doesn't help in any way if all localities are valid.)

However, when I try to write to this new space, I get an error.

jtt nv_write --file /tmp/64bytes --index 0x00011222


iaik.tc.tss.api.exceptions.tsp.TcTspException:
TSS Error:
error layer:                0x3000 (TSP)
error code (without layer): 0x02
error code (full):          0x3002
error message: An internal error has been detected, but the source is unknown.
additional info: illegal permissions - should not happen

        at iaik.tc.tss.impl.java.tsp.TcNvRam.writeValue(TcNvRam.java:371)
        at iaik.tc.apps.jtt.tboot.NvWrite.execute(NvWrite.java:87)
        at iaik.tc.utils.cmdline.SubCommand.run(SubCommand.java:69)
        at iaik.tc.utils.cmdline.SubCommandParser.parse(SubCommandParser.java:41)
        at iaik.tc.apps.JTpmTools.main(JTpmTools.java:198)

13:32:41:204 [ERROR] JTpmTools::main (209):     application exits with error:
TSS Error:
error layer:                0x3000 (TSP)
error code (without layer): 0x02
error code (full):          0x3002
error message: An internal error has been detected, but the source is unknown.
additional info: illegal permissions - should not happen
 (return: -1)


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.

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.

I've taken a look at rev 116 of the TPM spec (Ch  28 of Part 1, Ch 19
of Part 2, and Ch 20 of Part 3), and I can't find anything to suggest
that this is an illegal set of permissions for a TPM's NV space.

Looking at the TSS spec (TCG Software Stack (TSS) Specification
Version 1.2, Level 1, Errata A, Part 1: Commands and Structures, March
7, 2007), it looks like Tspi_NV_WriteValue can fail with any of the
following:

TSS_SUCCESS
TSS_E_INVALID_HANDLE
TSS_E_BAD_PARAMETER
TSS_E_INTERNAL_ERROR
TPM_BAD_INDEX
TPM_MAXNVWRITE
TPM_AUTH_CONFLICT
TPM_AUTHFAIL
TPM_AREA_LOCKED
TPM_BAD_LOCALITY
TPM_BAD_PRESENCE
TPM_DISABLED_CMD
TPM_NOSPACE
TPM_NOT_FULLWRITE
TPM_WRONGPCRVALUE

...however those correspond fairly nicely with the errors that the TPM
itself may generate.  I don't see anything that suggests I'm trying to
do something in violation of another layer's spec (I also checked the
PC Client spec).

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.

Many Thanks,
-Jon