trustedjava-support

[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

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

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

Hello again. :)

I follow-up with a second question that is different, but related.
Here I try to define space that exclusively depends upon the value of
PCR 10:

jtt nv_definespace --index 0x00011222 --size 64 -o tpm -e ASCII -p 10
-w --permission 0x00000000

14:05:13:544 [INFO] NvDefineSpace::execute (146):       Defining NV
space to depend on pcr: 10
iaik.tc.tss.api.exceptions.tcs.TcTcsException:
TSS Error:
error layer:                0x3000 (TSP)
error code (without layer): 0x03
error code (full):          0x3003
error message: unknown
additional info: no write permissions set

        at iaik.tc.tss.impl.java.tsp.TcNvRam.defineSpace(TcNvRam.java:168)
        at iaik.tc.apps.jtt.tboot.NvDefineSpace.execute(NvDefineSpace.java:240)
        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)

14:05:13:778 [ERROR] JTpmTools::main (209):     application exits with error:
TSS Error:
error layer:                0x3000 (TSP)
error code (without layer): 0x03
error code (full):          0x3003
error message: unknown
additional info: no write permissions set
 (return: -1)

In jtss_tsp/src/iaik/tc/tss/impl/java/tsp/TcNvRam.java, we see that
this is an exception that is thrown if no write permissions are set:

if (((permissions & TcTpmConstants.TPM_NV_PER_AUTHWRITE) == 0)
                                && ((permissions &
TcTpmConstants.TPM_NV_PER_OWNERWRITE) == 0)
                                && ((permissions &
TcTpmConstants.TPM_NV_PER_WRITEDEFINE) == 0)
                                && ((permissions &
TcTpmConstants.TPM_NV_PER_PPWRITE) == 0)
                                && !writeLocalities) {
                        throw new
TcTcsException(TcTcsErrors.TCS_E_BAD_PARAMETER,
                                        "no write permissions set");
                }


Again, what's the problem?  I did specify PCR-based access control for
writing.  Is there any fundamental reason why this shouldn't work?
The only thing I can think of is that NV space without any access
control might be more susceptible to malicious wear-out.

For both this and my previous message, I am happy to augment the code
with a patch that adds a check for a non-empty set of PCR-based
restrictions for writing.  From a design perspective, is there any
reason that this is not an acceptable set of restrictions?

Again, many thanks for your time and attention.
-Jon

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

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

On 2011-08-26 20:11, Jonathan McCune wrote:
> Hello again. :)

Hi again :)

> I follow-up with a second question that is different, but related.
> Here I try to define space that exclusively depends upon the value of
> PCR 10:
>
> jtt nv_definespace --index 0x00011222 --size 64 -o tpm -e ASCII -p 10
> -w --permission 0x00000000
>
> additional info: no write permissions set
>
>          at iaik.tc.tss.impl.java.tsp.TcNvRam.defineSpace(TcNvRam.java:168)
>
> In jtss_tsp/src/iaik/tc/tss/impl/java/tsp/TcNvRam.java, we see that
> this is an exception that is thrown if no write permissions are set:
>
> if (((permissions&  TcTpmConstants.TPM_NV_PER_AUTHWRITE) == 0)
>                                  &&  ((permissions&
> TcTpmConstants.TPM_NV_PER_OWNERWRITE) == 0)
>                                  &&  ((permissions&
> TcTpmConstants.TPM_NV_PER_WRITEDEFINE) == 0)
>                                  &&  ((permissions&
> TcTpmConstants.TPM_NV_PER_PPWRITE) == 0)
>                                  &&  !writeLocalities) {
>                          throw new
> TcTcsException(TcTcsErrors.TCS_E_BAD_PARAMETER,
>                                          "no write permissions set");
>                  }
>
> Again, what's the problem?  I did specify PCR-based access control for
> writing.  Is there any fundamental reason why this shouldn't work?
> The only thing I can think of is that NV space without any access
> control might be more susceptible to malicious wear-out.

The reason for this is that TPM Spec prohibits an index defined that way. You have 
to specify a write access restriction by either

TPM_NV_PER_OWNERWRITE,
TPM_NV_PER_AUTHWRITE,
TPM_NV_PER_WRITEDEFINE,
TPM_NV_PER_PPWRITE
or by excluding at least one locality.

This is specified in TPM Spec Commands, Revision 116, lines 4093 to 4107. jTSS 
just does the check before the command is actually send to the TPM.

You can either exclude one locality that you don't use (and won't be able to write 
to this index using jTSS) or you use the TPM_NV_PER_AUTHWRITE method.

> Again, many thanks for your time and attention.
> -Jon

Best regards,
Michael

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

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

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

Hi Michael,

Thanks for both of your emails.

> The problem is that jTSS doesn't support unauthenticated commands.

I don't fully understand the scope of this limitation, as the TPM
supports many commands that do not require authentication.

Are there plans for jTSS to ever support unauthenticated NVRAM commands?

I'm trying to discern whether these issues are symptomatic of a
work-in-progress, or if they are by design. And if so, why?

Thanks,
-Jon

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

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

Hi Jon,

On 08/29/2011 04:46 PM, Jonathan McCune wrote:
>> The problem is that jTSS doesn't support unauthenticated commands.
> I don't fully understand the scope of this limitation, as the TPM
> supports many commands that do not require authentication.
jTSS handles each commands in a uniform way. Once authentication is 
required in one case, it is in all.

> Are there plans for jTSS to ever support unauthenticated NVRAM commands?
Currently none; usually, TSS_WELL_KNOWN_SECRET serves very well as an 
substitute. Also, most object get this set as their default policy, so 
that the user experience usually does not suffer at all.

It is certainly possibly to make an exception for a small set of 
commands and add the necessary if clauses in all layers (tsp, soap, tcs).

> I'm trying to discern whether these issues are symptomatic of a
> work-in-progress, or if they are by design. And if so, why?
It's a pragmatic compromise, due to limited (human) resources.

Ronald

-- 
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