How to block other users from reading in an nv index

[GaspardLauras]

Hello,

I am trying to store data persistently in my TPM. For this, I am using the tpm2 nvdefine, tpm2 nvwrite and tpm2 nvread functions. I first followed the example presented here : tpm2_nvread and it worked fine. However, I would like to prevent other users then the one writting in the nv index to be able to read the said data.

I tried to use the -p options in tpm2 nvdefine but I can't find the equivalent parameteri in tpm2 nvwrite and tpm2 read commands manpages. It however worked with the nvwrite but it gets me an error when I try the nvread command.

Here is the exact command sequence I have used :

$ tpm2 nvdefine -s 64 -p=pass 1
nv-index: 0x1000001
$ echo "SECRET PASS 123456" > nv.dat
$ tpm2 nvwrite -i nv.dat 1 -P=pass
$ tpm2 nvread -s 64 1 -P=pass
ERROR:esys:src/tss2-esys/esys_iutil.c:1107:esys_GetResourceObject() Error: Esys handle does not exist (70018).
ERROR: Esys_SequenceComplete(0x70018) - esapi:The ESYS_TR resource object is bad
ERROR: Failed to get shandle
ERROR: Failed to read NVRAM area at index 0x1000001
ERROR: Unable to run nvread

What is/are my mistakes? Maybe there is a better way to store data persistently and prevent users from accessing it?

Thank you for your help

[williamcroberts]

That seems more like a bug, because it works for me:

tpm2 nvdefine -s 64 -p=pass 1
nv-index: 0x1000001
echo "SECRET PASS 123456" > nv.dat
tpm2 nvwrite -i nv.dat 1 -P=pass
tpm2 nvread -s 64 1 -P=pass
SECRET PASS 123456
���������������������������������������������

[williamcroberts]

What's your versions of stuff?

[GaspardLauras]

I have these :

$ tpm2 -v
tool="tpm2" version="5.2" tctis="libtss2-tctildr" tcti-default=tcti-device

Also I have been trying to do something similar by using the example here and adding an evictcontrol as follows :

#! /bin/bash

rm handle
tpm2 clear

tpm2_createprimary -c primary.ctx -p kali -Q
echo '>>> DONE createprimary'

tpm2_getrandom 32 --hex | tpm2_create -C primary.ctx -P kali -i - -u key.pub -r key.priv -Q 
echo '>>> DONE getrandom / create'

tpm2_load -C primary.ctx -P kali -u key.pub -r key.priv -c key.ctx -Q 
echo '>>> DONE load'

tpm2_evictcontrol -c key.ctx | grep persistent-handle | cut -d ' ' -f2 > handle
echo '>>> DONE evictcontrol'

cat handle 

rm primary.ctx key*

and

$  tpm2_unseal -c $(cat handle)
e657757d9fbfb7ccbbe3334d819ca0598cf0cceecd217fd3b048e6974b07a32d

But the access to the data stored in handle is not protected either so I guess I really have to use NV indexes

[JuergenReppSIT]

you should use the option -p kali for the command tpm2_create to protect the sealed data. -P is used to authorize the parent object.

[GaspardLauras]

It works perfectly, thank you very much for your help

[nicowilliams]

@williamcroberts how do commands like tpm2_nvwrite and tpm2_nvread which do not take a session nor an authValue for the object itself (those two take only an "authorization value for the hierarchy") actually handle authorization?

I think for NV indices there's no hierarchy involved anyways, so at the very least the manual pages for tpm2_nvwrite and tpm2_nvread are in error, but so is their source code since they refer to the authValues as being the hierarchy's.

[williamcroberts]

@williamcroberts how do commands like tpm2_nvwrite and tpm2_nvread which do not take a session nor an authValue for the object itself (those two take only an "authorization value for the hierarchy") actually handle authorization?

You can use either the hierarchy or the NV index handle itself to authorize access.

I think for NV indices there's no hierarchy involved anyways, so at the very least the manual pages for tpm2_nvwrite and tpm2_nvread are in error, but so is their source code since they refer to the authValues as being the hierarchy's.

They support both

[nicowilliams]

@williamcroberts I see that now. Thanks.