Forgive me if this is obvious to you :-) but I'd like to understand and
clarify the above a bit more. In the procedure you've presented above does
step #4 change the state of the session to one that can be used?

Is then the procedure then something like:

1. tpm2_createpolicy - create a pcr policy and spit out the policy digest

eg: I create a policy based upon the current state of (eg) sha1:0,1,2,3 and
save this as  0123.policy

2. tpm2_create - create an object containing the policy created in #1 (+
keys?)

eg: I create an object which is sealed (???) against 0123.policy

Question: is there a need to perform a tpm2_load here or is it sufficient
that this exists temporarily?

3. tpm2_startauthsession - create a session handle for a given pcr policy

eg: I generate a session handle for a given policy, eg: 0123.policy and
return this as, say   session.bin

4. tpm2_policypcr, given #1 and #3, check if either a supplied set of PCR
values or the current state of the PCR registers are specified in #1 match,
if so then the session handle is marked as being valid until step #6

5. tpm2_* with -S taking the output of #3 as input as required

Question: what happens if I issue a tpm2_* command without -S during this
time?

6. tpm2_flushcontext   taking the session handle and/or  object from #2 as
input.  Any further attempts to use the session handle with tpm2_* -S
fails.


So an example session might proceed

$tpm2_createpolicy -P -f 0123.policy -g sha256 -L sha1:0,1,2
$ls
0123.policy
$tpm2_create -H 0x81010001 -g sha256 -G rsa -L 0123.policy
0x810100ff         <- output handle, also assume 0x81010001 exists in the
above
$tpm2_startauthsession -L 0123.policy -s session.bin
$ls
session.bin

Now this is pure guesswork here

$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
FAIL

$tpm2_policypcr -k 0x81010001 -s session.bin -L
0123.policy                    <- reads sha1:0,1,2,3 from the TPM
OK

$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
$cat plain.txt
"This is a secret message"

$tpm2_flushcontext -H 0x810100ff            <- our object from above

$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
FAIL




t.

Ian



On 19 December 2017 at 20:01, Roberts, William C <
william.c.roberts(a)intel.com> wrote:

> There are two main parts to the direction I see the tools policy/session
> support heading:
>
> 1. The first is cleaning up all the code around session support and policy
> building.  I think now that I understand the topic better, I can organize
> this code a little better. This is rather trivial and beside the main point.
>
> 2. Since abrmd 1.3 we have support for sessions across RM IPC connections
> and direct tpm communications (/dev/tmp0) also has the same support. We
> have tools like tpm2_createpolicy that are made up of multiple
> commands to work around session flushing on IPC RM disconnections.
> tpm2_createpolicy is really comprised of 3 commands: tpm2_startauthsession,
> tpm2_policypcr and tpm2_flushcontext.
>
> I'm proposing we leave tpm2_createpolicy, for in-kernel-rm users, but add
> tpm2_startauthsession and tpm2_policypcr for the abrmd and direct tpm
> usages. Abrmd works by using Tss2_Sys_ContextSave as the
> marker of NOT flushing a session handle. Granted you also need the
> sessionAttributes set to continue so the TPM doesn't kill it.
>
> I think the flow for using the new tools would be something like this:
>
> 1. tpm2_createpolicy - create a pcr policy and spit out the policy digest
> 2. tpm2_create - create an object and set its policy digest as obtained in
> step 1
> 3. tpm2_startauthsession - create a pcr policy and spit out the session
> handle
> 4. tpm2_policypcr - satisfy policy via policy digest and pcr list
> obtained/used in step 1 as well as taking the session handle from step 3
> 5. tpm2_<tool> - use some tool passing the session handle from step 3
> 6. tpm2_flushcontext - flushes the handle from step 3
>
> With that said, since tpm2_createpolicy is really a combination of the
> tpm2_startauthsession, tpm2_pcrlist, tpm2_policypcr and tpm2_flushcontext,
> all that could be moved into lib, so each new tool and
> create policy are really just calling into the same code.
>
> Thoughts, am I missing something here?
>
> This is a lot of work, so I would like to start it now, as it would be the
> major feature set going towards 4.0 release.
>
> Bill
> _______________________________________________
> tpm2 mailing list
> tpm2(a)lists.01.org
> https://lists.01.org/mailman/listinfo/tpm2
>



-- 
*Dr. Ian Oliver*
===============================
Privacy Engineering:  via Amazon <http://www.amazon.co.uk/dp/1497569710>
*Twitter: @i_j_oliver*