Re: [tpm2] [RFC] Session Handling/Policy Support in Tools

Re: [tpm2] [RFC] Session Handling/Policy Support in Tools

[Desai, Imran]

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

Hello Bill,

This (attached diagram) is what my thought process was, when designing the createpolicy tool.
I concur the startauthsession and flushcontext can be separate tools that are currently clubbed in the createpolicy tool.

[cid:CC18E3F2-C642-4662-9CEC-C1091AA18831(a)amr.corp.intel.com]

Thanks and Regards,

Imran Desai  | imran.desai(a)intel.com<mailto:imran.desai(a)intel.com>




On Dec 19, 2017, at 11:01 AM, Roberts, William C <william.c.roberts(a)intel.com<mailto: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


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4756 bytes --]

[-- Attachment #3: PastedGraphic-1.png --]
[-- Type: image/png, Size: 343937 bytes --]

Re: [tpm2] [RFC] Session Handling/Policy Support in Tools

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 7191 bytes --]



> -----Original Message-----
> From: Roberts, William C
> Sent: Tuesday, December 26, 2017 9:40 AM
> To: Javier Martinez Canillas <javierm(a)redhat.com>; tpm2(a)lists.01.org
> Subject: RE: [tpm2] [RFC] Session Handling/Policy Support in Tools
> 
> 
> 
> > -----Original Message-----
> > From: Javier Martinez Canillas [mailto:javierm(a)redhat.com]
> > Sent: Friday, December 22, 2017 7:15 AM
> > To: Roberts, William C <william.c.roberts(a)intel.com>;
> > tpm2(a)lists.01.org
> > Subject: Re: [tpm2] [RFC] Session Handling/Policy Support in Tools
> >
> > Hello Bill,
> >
> > On 12/19/2017 07:01 PM, Roberts, William C 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.
> >
> > Agreed, I've seen your PR in the repo and I think it's good.
> >
> > >
> > > 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.
> > >
> >
> > Absolutely agree. And as a matter of fact that's exactly what's done
> > by the IBM TSS, it has separate tools called startauthsession, policypcr and
> 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
> >
> > Agreed too.
> >
> > > marker of NOT flushing a session handle. Granted you also need the
> > sessionAttributes set to continue so the TPM doesn't kill it.
> > >
> >
> > Yes, in fact I don't know how chaining different commands with the
> > current -S option that takes a session handle is working nowadays
> > since the tools aren't setting the continueSession attribute. I guess the answer
> is that it doesn't?
> >
> > > I think the flow for using the new tools would be something like this:
> > >
> >
> > NOTE: I haven't looked at the final tpm2-abrmd implementation, I'm
> > assuming that
> >       it was implemented as previously discussed in the GitHub issues so please
> >       let me know if I got some assumption wrong in the following:
> >
> > > 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
> >
> > To be precise, this tool won't sit out a session handle but a session
> > context (what's returned by a TPM2_ContextSave() command), right?
> > Otherwise the session will be flushed by the tpm2-abrmd since a call
> > to Tss2_Sys_ContextSave() won't be made.
> 
> Correct. It needs to call ContextSave() for abrmd to mark it as not to be flushed.
> It also need the continue bits set on the session IIUC.
> 
> >
> > > 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
> >
> > This will work for a single tool, but my understanding is that
> > sessions that are saved with TPM2_ContextSave() can only be loaded
> > once to prevent replay attacks.
> >
> > So the tpm2_<tool> should both get a session context and load it using
> > the
> > TPM2_ContextLoad() command and export it again using a
> TPM2_ContextSave().
> >
> > The next command can't use the same saved session context that the
> > previous command since the TPM will prevent it to be loaded. Even if
> > the TPM would allow, the session handle would already be flushed since
> > TPM2_ContextLoad() wouldn't be called before closing the SAPI connection.

Hmm I missed some of this yesterday in my reply. I guess a lot of this depends
on what the RM is doing, if ContextSave() on the session handle
actually hits the TPM with abrmd, and if abrmd requires a ContextSave() on every
client that uses the session handle to keep it alive. Maybe something like

# calls context save but just deletes the file...
$ tpm2_startauthsession
handle: 0x1234

# abrmd keeps this handle alive until flush
tpm2_policypcr -S 0x1234 

$ tpm2_tool1 -S 0x1234

$ tpm2_tool2 -S 0x1234 

$ tpm2_flush 0x12334 

This really depends on abrmd, but I'd like whatever works with abrmd to work
against a raw device directly as well.

This seems to be getting wonky.

> >
> > > 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.
> > >
> >
> > Agreed, I factored out a little bit so at least the tools that are
> > doing the session auth on each execute wouldn't duplicate the code.
> > But we will need to better split things since some functions logic are too
> monolithic.
> >
> > > Thoughts, am I missing something here?
> > >
> >
> > I think your plan is the correct one. One question is if we will
> > replace the -S option that takes a session handle and instead take a
> > session context or if we will want to support the 3 options:
> 
> I don't think I made that clear, but I plan on -S to support:
> 1. a hex handle
> 2. a file path.
> 
> In the case of a file path, it would call context load/save every-call, so essentially -
> S is both an input and output parameter via a file and that would get us around
> the 1 load per handle IIUC. Whenever -S is specified, the continueSession bit will
> get set so the TPM itself doesn't flush it.
> 
> >
> > 1) Chain tools passing session handles as long as are executed in an
> environment
> >    that doesn't close the SAPI context (and so flushes the session).
> > 2) Allow individual tools to manage their own session and auth like is the case
> >    for tpm2_unseal and tpm2_nv{read,write}
> > 3) Chain tools by passing saved session contexts.
> >
> > In theory we currently support 1 and 2 (although as mentioned I don't
> > know how
> > 2 works if the tools don't set continueSession). So my question is if
> > we want to also include 3 or replace 2 by 3.
> >
> > > 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.
> > >
> >
> > Best regards,
> > --
> > Javier Martinez Canillas
> > Software Engineer - Desktop Hardware Enablement Red Hat

Re: [tpm2] [RFC] Session Handling/Policy Support in Tools

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 5908 bytes --]



> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javierm(a)redhat.com]
> Sent: Friday, December 22, 2017 7:15 AM
> To: Roberts, William C <william.c.roberts(a)intel.com>; tpm2(a)lists.01.org
> Subject: Re: [tpm2] [RFC] Session Handling/Policy Support in Tools
> 
> Hello Bill,
> 
> On 12/19/2017 07:01 PM, Roberts, William C 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.
> 
> Agreed, I've seen your PR in the repo and I think it's good.
> 
> >
> > 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.
> >
> 
> Absolutely agree. And as a matter of fact that's exactly what's done by the IBM
> TSS, it has separate tools called startauthsession, policypcr and 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
> 
> Agreed too.
> 
> > marker of NOT flushing a session handle. Granted you also need the
> sessionAttributes set to continue so the TPM doesn't kill it.
> >
> 
> Yes, in fact I don't know how chaining different commands with the current -S
> option that takes a session handle is working nowadays since the tools aren't
> setting the continueSession attribute. I guess the answer is that it doesn't?
> 
> > I think the flow for using the new tools would be something like this:
> >
> 
> NOTE: I haven't looked at the final tpm2-abrmd implementation, I'm assuming
> that
>       it was implemented as previously discussed in the GitHub issues so please
>       let me know if I got some assumption wrong in the following:
> 
> > 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
> 
> To be precise, this tool won't sit out a session handle but a session context
> (what's returned by a TPM2_ContextSave() command), right? Otherwise the
> session will be flushed by the tpm2-abrmd since a call to Tss2_Sys_ContextSave()
> won't be made.

Correct. It needs to call ContextSave() for abrmd to mark it as not to be flushed.
It also need the continue bits set on the session IIUC.

> 
> > 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
> 
> This will work for a single tool, but my understanding is that sessions that are
> saved with TPM2_ContextSave() can only be loaded once to prevent replay
> attacks.
> 
> So the tpm2_<tool> should both get a session context and load it using the
> TPM2_ContextLoad() command and export it again using a TPM2_ContextSave().
> 
> The next command can't use the same saved session context that the previous
> command since the TPM will prevent it to be loaded. Even if the TPM would
> allow, the session handle would already be flushed since TPM2_ContextLoad()
> wouldn't be called before closing the SAPI connection.
> 
> > 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.
> >
> 
> Agreed, I factored out a little bit so at least the tools that are doing the session
> auth on each execute wouldn't duplicate the code. But we will need to better
> split things since some functions logic are too monolithic.
> 
> > Thoughts, am I missing something here?
> >
> 
> I think your plan is the correct one. One question is if we will replace the -S option
> that takes a session handle and instead take a session context or if we will want
> to support the 3 options:

I don't think I made that clear, but I plan on -S to support:
1. a hex handle
2. a file path.

In the case of a file path, it would call context load/save every-call, so essentially
-S is both an input and output parameter via a file and that would get us around the 1
load per handle IIUC. Whenever -S is specified, the continueSession bit will get set
so the TPM itself doesn't flush it.

> 
> 1) Chain tools passing session handles as long as are executed in an environment
>    that doesn't close the SAPI context (and so flushes the session).
> 2) Allow individual tools to manage their own session and auth like is the case
>    for tpm2_unseal and tpm2_nv{read,write}
> 3) Chain tools by passing saved session contexts.
> 
> In theory we currently support 1 and 2 (although as mentioned I don't know how
> 2 works if the tools don't set continueSession). So my question is if we want to
> also include 3 or replace 2 by 3.
> 
> > 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.
> >
> 
> Best regards,
> --
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement Red Hat

Re: [tpm2] [RFC] Session Handling/Policy Support in Tools

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 4082 bytes --]

Hello Ian,

On 12/20/2017 03:35 PM, Ian Oliver wrote:
> 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?
>

You always need to do a TPM2_Load if you want to use an object created by the
TPM. The TPM2_Create commands just returns the public and private parts of an
object but doesn't keep anything in the TPM memory after is completed.
 
> 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
>

No, here Bill weren't precise in the wording AFAICT. He said "creates a session
handle for a given pcr policy" but he should had said "creates a session handle
for a given session policy".

In other words, you are just creating an authentication session but still didn't
do any authentication based on the PCR state.

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

Yes, this tool will send a TPM2_PolicyPCR() command to the TPM with the PCR
digest and so the session is changed from policySession to policyDigest.

About the session handle being valid until #6, this really depends if the
command sets TPM_ST_SESSIONS in the header tag field or TPM_ST_NO_SESSIONS?

If the latter, the provided session is flushed after the command completes
unless the policySession continueSession attribute is SET.

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

If you are not provided a session that could satisfy the authentication
policy for your object, then the TPM will refuse the command to succeed
returning a TPM2_RC_BAD_AUTH response code as an error.

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

Yes. After the session handle has been flushed from the TPM, any attempts
to authenticate using it will fail (in fact the session context won't even
load AFAICT).

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

Yes, this is mostly correct. Please read my previous emails regardless
some of the details, but in general it will work as you said.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [tpm2] [RFC] Session Handling/Policy Support in Tools

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

Hello Bill,

On 12/19/2017 07:01 PM, Roberts, William C 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.

Agreed, I've seen your PR in the repo and I think it's good.

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

Absolutely agree. And as a matter of fact that's exactly what's done by the IBM
TSS, it has separate tools called startauthsession, policypcr and 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

Agreed too.

> marker of NOT flushing a session handle. Granted you also need the sessionAttributes set to continue so the TPM doesn't kill it.
>

Yes, in fact I don't know how chaining different commands with the current -S
option that takes a session handle is working nowadays since the tools aren't
setting the continueSession attribute. I guess the answer is that it doesn't?

> I think the flow for using the new tools would be something like this:
>

NOTE: I haven't looked at the final tpm2-abrmd implementation, I'm assuming that
      it was implemented as previously discussed in the GitHub issues so please
      let me know if I got some assumption wrong in the following:

> 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

To be precise, this tool won't sit out a session handle but a session context
(what's returned by a TPM2_ContextSave() command), right? Otherwise the session
will be flushed by the tpm2-abrmd since a call to Tss2_Sys_ContextSave() won't
be made.

> 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

This will work for a single tool, but my understanding is that sessions that
are saved with TPM2_ContextSave() can only be loaded once to prevent replay
attacks.

So the tpm2_<tool> should both get a session context and load it using the
TPM2_ContextLoad() command and export it again using a TPM2_ContextSave().

The next command can't use the same saved session context that the previous
command since the TPM will prevent it to be loaded. Even if the TPM would
allow, the session handle would already be flushed since TPM2_ContextLoad()
wouldn't be called before closing the SAPI connection.

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

Agreed, I factored out a little bit so at least the tools that are doing
the session auth on each execute wouldn't duplicate the code. But we will
need to better split things since some functions logic are too monolithic.

> Thoughts, am I missing something here?
>

I think your plan is the correct one. One question is if we will replace the
-S option that takes a session handle and instead take a session context or
if we will want to support the 3 options:

1) Chain tools passing session handles as long as are executed in an environment
   that doesn't close the SAPI context (and so flushes the session).
2) Allow individual tools to manage their own session and auth like is the case
   for tpm2_unseal and tpm2_nv{read,write}
3) Chain tools by passing saved session contexts.

In theory we currently support 1 and 2 (although as mentioned I don't know how
2 works if the tools don't set continueSession). So my question is if we want
to also include 3 or replace 2 by 3.

> 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.
>
 
Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [tpm2] [RFC] Session Handling/Policy Support in Tools

[Ian Oliver]

[-- Attachment #1: Type: text/plain, Size: 4842 bytes --]

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*

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6569 bytes --]

[tpm2] [RFC] Session Handling/Policy Support in Tools

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

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