Question: PasswordTest with tpm2-tools

[romansil]

Hi,

I'm trying to understand the authorizations in the TPM protocol. Therefor I wanted to repoduce the behavior of the tpm2-tss test PasswordTest(src) with the tpm2-tools. For testing I use the IBM TPM 947 emulator, tpm-tools v2.0.0 and tpm-tss 1.0.
I tried that with the following commands:

tpm2_startup --clear
tpm2_nvdefine -x 0x1500015 -a 0x4000000C -s 32 -t 0x44014001 -I "test password"
echo "foo bar" > nv.data
tpm2_nvwrite -x 0x1500015 -a 0x4000000C -f nv.data -P "test password"

This brings me to the following error:

ERROR: Failed to write NV area at index 0x1500015 (22020117) offset 0x0. Error:0x9a2

Decoding with tpm2_rc_decode:

error layer
hex: 0x0
identifier: TSS2_TPM_ERROR_LEVEL
description: Error produced by the TPM
format 1 error code
hex: 0x22
identifier: TPM_RC_BAD_AUTH
description: authorization failure without DA implications
session
hex: 0x100
identifier: TPM_RC_1
description: (null)

Writing without passwords and the attribute -t 0x2000A works. But that means no authorization at all.

Have I misinterpreted the testcase?
Can anyone explain, what's the -I ,--indexPasswd argument good for?

Kind regards,
Roman

[williamcroberts]

Please post questions to the mailing list. Their are folks far more knowledgeable than I on there.

With that said, looking through the test code you mention and the tools test suite, there is no define with a password and test case. The TSS code tests for auth failed.

FYI: It's easier if you list the nv attributes in a human readable form. Master branch supports this is well. No need for hex masks anymore.
You set attributes:

TPMA_NV_OWNERWRITE
TPMA_NV_WRITE_STCLEAR
TPMA_NV_PLATFORMCREATE

I went through and looked at the call to Tss2_Sys_NV_Write in the tool:
I got:

authHandle: 0x4000000C (TPM_RH_PLATFORM)
Within Session Data:
sessionHandle: 0x40000009 (TPM_RS_PW)
nonce: clear
sessionAttributes: clear
hmac: .t = { .size = 13, .buffer="test password" }

I am not 100% sure if this is:

1. a bug in the tools
2. a mistake in the attributes
3. a mistake in using the tools

[williamcroberts]

Looks like a bug in the tool:
#297

[williamcroberts]

Im actually going to reopen this as a ticket with "no tools test password authorization on nv-index access"

Section 31.1 in:
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-3-Commands-01.38.pdf

An Index may have an Index-specific authValue and authPolicy. The authValue may be used to authorize
reading if TPMA_NV_AUTHREAD is SET and writing if TPMA_NV_AUTHWRITE is SET. The authPolicy
may be used to authorize reading if TPMA_NV_POLICYREAD is SET and writing if
TPMA_NV_POLICYWRITE is SET.
For commands that have both authHandle and nvIndex parameters, authHandle can be an NV Index,
Platform Authorization, or Owner Authorization. If authHandle is an NV Index, it must be the same as
nvIndex (TPM_RC_NV_AUTHORIZATION).

It looks like your attributes are wrong based on this paragraph.

[williamcroberts]

I tried:

# We want to define an nv index that requires password foo for read and write
$ tpm2_nvdefine -x 0x1500015 -a 0x40000001 -s 32 -t 'policyread|policywrite|authread|authwrite' -I "foo"

# We want this to fail but it succeeds
$ tpm2_nvwrite -x 0x1500015 -a 0x40000001 ~/a.dat

# We want read to fail with 0x149 : TPM_RC_NV_AUTHORIZATION
# And it does
# tpm2_nvread -x 0x1500015 
ERROR: Failed to read NVRAM area at index 0x1500015 (22020117). Error:0x149

# Now we try and pass "foo" as a password and it should work but doesnt, Errors with
# TPM_RC_BAD_AUTH
$ tpm2_nvread -x 0x1500015 -a 0x40000001 -P foo
ERROR: Failed to read NVRAM area at index 0x1500015 (22020117). Error:0x9a2

[romansil]

Thanks for your help! Sorry I don't know which mailing list you mean.

I guess that I can't help to fix the bug, since my knowledge of TPMs is poor. I tried to marshal the commands myself and compared it with the tpm2-tools. My observations are, that the password specified with tpm2_nvdefine -I parameter goes into the auth field described in "TPM2_NV_DefineSpace Command and Response" (TPM Library Specification Part 3, Section 31.3.2). Where the -P parameter of the tpm2_write command lives in the TPMS_AUTH_COMMAND struct (placed in the hmac field). The -P parameter can also be set at tpm2_nvdefine. Then it is also set in TPMS_AUTH_COMMAND.

One example where this is used can be found in the wiki:
https://github.com/01org/tpm2-tools/wiki/How-to-use-tpm2-tools

tpm2_takeownership -o ownerpass -e endorsepass -l lockpass
tpm2_nvdefine -x 0x1500001 -a 0x40000001 -s 32 -t 0x2000A -P ownerpass
tpm2_nvwrite -x 0x1500001 -a 0x40000001 -f nv.data -P ownerpass

That works on my system. But I interpret this setting a password for the whole TPM_RH_OWNER hierarchy. And that's not the purpose of an index password, if I understood this correctly.

[romansil]

I think I found my problem. To use the index password, the authHandle (parameter a) has to be set to the index handle. The following commands summarize

#                                                 0xc000c = policyread|policywrite|authread|authwrite
tpm2_nvdefine -x 0x1500015 -a 0x40000001 -s 32 -t 0xc000c -I "foo"
# succeeds as expected

tpm2_nvwrite -x 0x1500015 -a 0x1500015 -f ~/a.dat -P "foo"
# succeeds as expected
tpm2_nvwrite -x 0x1500015 -a 0x1500015 -f ~/a.dat -P "wrong"
# fails as expected error 0x98e = TPM_RC_AUTH_FAIL
tpm2_nvwrite -x 0x1500015 -a 0x40000001 -f ~/a.dat
# fails as expected error 0x149 = TPM_RC_NV_AUTHORIZATION
tpm2_nvwrite -x 0x1500015 -a 0x40000001 -f ~/a.dat  -P "wrong"
# fails as expected error 0x9a2 = TPM_RC_BAD_AUTH

tpm2_nvread -x 0x1500015 -a 0x1500015 -s 32 -o 0 -P "foo"
# succeeds as expected
tpm2_nvread -x 0x1500015 -a 0x1500015 -s 32 -o 0 -P "wrong"
# fails as expected error 0x98e = TPM_RC_AUTH_FAIL
tpm2_nvread -x 0x1500015 -a 0x40000001 -s 32 -o 0
# fails as expected error 0x149 = TPM_RC_NV_AUTHORIZATION
tpm2_nvread -x 0x1500015 -a 0x40000001 -s 32 -o 0 -P "foo"
# fails as expected error 0x9a2 = TPM_RC_BAD_AUTH

The index attribute (tpm2_nvdefine -t) can be set to 0x40004 = authread|authwrite, that brings me to the same result.

Please keep in mind, that I'm using tpm-tools v2.0.0 and tpm-tss 1.0, so maybe there is a bug in the current version. I leave it up to you, to close the issue.
Thank you William for your time!

[williamcroberts]

For the mailing list, see the support section in the README.md file. This mailing list is: https://lists.01.org/mailman/listinfo/tpm2 From: Roman Silberschneider [mailto:notifications@github.com] Sent: Friday, October 27, 2017 12:34 AM To: 01org/tpm2-tools <tpm2-tools@noreply.github.com> Cc: Roberts, William C <william.c.roberts@intel.com>; State change <state_change@noreply.github.com> Subject: Re: [01org/tpm2-tools] Question: PasswordTest with tpm2-tools (#580) Thanks for your help! Sorry I don't know which mailing list you mean. I guess that I can't help to fix the bug, since my knowledge of TPMs is poor. I tried to marshal the commands myself and compared it with the tpm2-tools. My observations are, that the password specified with tpm2_nvdefine -I parameter goes into the auth field described in "TPM2_NV_DefineSpace Command and Response" (TPM Library Specification Part 3, Section 31.3.2). Where the -P parameter of the tpm2_write command lives in the TPMS_AUTH_COMMAND struct (placed in the hmac field). The -P parameter can also be set at tpm2_nvdefine. Then it is also set in TPMS_AUTH_COMMAND. One example where this is used can be found in the wiki: https://github.com/01org/tpm2-tools/wiki/How-to-use-tpm2-tools tpm2_takeownership -o ownerpass -e endorsepass -l lockpass tpm2_nvdefine -x 0x1500001 -a 0x40000001 -s 32 -t 0x2000A -P ownerpass tpm2_nvwrite -x 0x1500001 -a 0x40000001 -f nv.data -P ownerpass That works on my system. But I interpret this setting a password for the whole TPM_RH_OWNER hierarchy. And that's not the purpose of an index password, if I understood this correctly. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#580 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQ7bBwB8VzEdr7dTK-bVCj7wLKd2g0jVks5swYd2gaJpZM4QFfKg>.

[idesai]

@romansil @williamcroberts to reconcile the two problems here:
(1) Index attributes. 0x40004 or 0xC000C is a way to enforce index passwords instead of hierarchy
(2) In NV define space an hierarchy authorization is needed to be able to create an NV index under the hierarchy. But optionally you can also set index password when defining the space and enforce its usage with appropriate attributes. Unlike define space however, NV write or read takes one authorization (pw or policy) for either index or hierarchy depending on how attributes are setup. So when writing or reading the index with index password, the index handle should be specified. Eg: tpm2_nvread -x 0x1500015 -a 0x1500015 -s 32 -o 0 -P "foo" above.

[idesai]

btw @williamcroberts wasssup with all tools now displaying this message in latest master
ERROR: Unknow TPM_SPEC. spec_level: 0, spec_rev: 0x8a, year: 2016, day_of_year: 316
WARN: TPM errata info is unavailable
if this is some error checking on errata for specifications, should this message be displayed on every tool run?

[martinezjavier]

@idesai I think it's a bug in the errata infrastructure code. It shouldn't be an error if an errata isn't defined by a particular spec <level,rev,year,day>. Same for the WARN: TPM errata info is unavailable printout.

Or alternatively, all the published specifications and errata versions should be added to the known_errata_info table.

[williamcroberts]

#590

[williamcroberts]

I thought I actually tried setting the auth handle to the pcr index and it didn't work... let me try again.