-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misleading command invocation nvram.md/sealing #22
Comments
Thanks,
the course and those commands are pretty old now. At least when I wrote it
originally the above was the case.
I no longer work for Nokia, so I'm wondering what to do with that course
--- I've been teaching it at universities (or actually using that material
as part of the TPM part of my courses)....there's a book due out "real soon
now"
t.
Ian
…On Mon, 1 Jul 2024 at 03:11, SharkOverBite ***@***.***> wrote:
The "Sealing" section of nvram.md demonstrates the following command
sequence:
$ tpm2_pcrread -o srtm.pcrvalues sha256:0,1,2,3
$ tpm2_createpolicy --policy-pcr -l sha256:0,1,2,3 -f srtm.pcrvalues -L srtm.policy
$ tpm2_nvdefine 0x1500019 -C o -s 32 -L srtm.policy -a "policyread|policywrite"
$ tpm2_nvwrite 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues -i testfile
$ tpm2_nvread 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues
You don't *have* to provide a file for tpm2_createpolicy, it will
implicitly use the current values of the specified PCRs.
But you show a more general case, and that's fine.
However, the inclusion of "=srtm.pcrvalues" in the last two command, to
tpm2_nvwrite and tpm2_nvread is totally bogus,
and arguably should raise an error from the tpm2-tools parser. Obviously,
when invoking those commands with a PCR policy, this file is completely
irrelevant. The source of the PCR values is (and must be) only the current
state of the linked PCRs on the device.
—
Reply to this email directly, view it on GitHub
<#22>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHKY2MKEAHZ6UJB7U53LUM3ZKCNEDAVCNFSM6AAAAABKEQZHDSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM4DENJRG4YDCNY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I understand. There's still, after all these years, a great lack of good, well-written (I can't bold that enough), procedural documentation about TPM. This one is better than most, though quite focused on attestation use-cases (which I care less about). I have verified that the commands work without specifying the file (as logically, they must - what are the semantics of attaching the file??). Since I've opened an issue on tpm2-tools, we'll have to see what they have to say about it. Good luck with the book (when and if). If it's well-written, I'd love to read it. |
Thanks,
yes, I certainly share your comment on a lack of procedural
documentation. I worked extensively with attestation, hence the emphasis
there ( even wrote the "best" attestation server ever ! )
I'll probably fork the course and rewrite it over the next few weeks - will
go alongside the courses I teach and the upcoming "real soon now" book
t.
Ian
…On Mon, 1 Jul 2024 at 18:11, SharkOverBite ***@***.***> wrote:
I understand. There's still, after all these years, a great lack of good,
*well-written* (I can't bold that enough), procedural documentation about
TPM. This one is better than most, though quite focused on attestation
use-cases (which I care less about).
I have verified that the commands work without specifying the file (as
logically, they must, what are the semantics of attaching the file??).
Since I've opened an issue on tpm2-tools, we'll have to see what they have
to say about it.
Good luck with the book (when and if). If it's well-written, I'd love to
read it.
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHKY2MIQYKJ7L5V3DFMEGADZKFWR3AVCNFSM6AAAAABKEQZHDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQGQZDGNRZGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Looking forward to the fruits of your many labors. 👍 |
tpm2-software/tpm2-tools say I'm wrong, that it's not an error but an optimization which supposedly saves another step by the device IIUC. I don't understand their response to be honest. |
The "Sealing" section of nvram.md demonstrates the following command sequence:
$ tpm2_pcrread -o srtm.pcrvalues sha256:0,1,2,3 $ tpm2_createpolicy --policy-pcr -l sha256:0,1,2,3 -f srtm.pcrvalues -L srtm.policy $ tpm2_nvdefine 0x1500019 -C o -s 32 -L srtm.policy -a "policyread|policywrite" $ tpm2_nvwrite 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues -i testfile $ tpm2_nvread 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues
You don't have to provide a file for tpm2_createpolicy, it will implicitly use the current values of the specified PCRs.
But you show a more general case, and that's fine.
However, the inclusion of "=srtm.pcrvalues" in arguments for the last two
tpm2_nvwrite
andtpm2_nvread
commands is totally bogus,and arguably should raise an error from the tpm2-tools parser. Obviously, when invoking those commands with a PCR policy, the contents of that are irrelevant. The source of the PCR values is (and must be) only the current state of the specified PCRs, on the device.
The text was updated successfully, but these errors were encountered: