[tpm2] Re: Lifecycle of handles and contexts

[tpm2] Re: Lifecycle of handles and contexts

[Roberts, William C]

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

On Sat, 2022-07-16 at 14:20 +0000, Tim K wrote:
> Is there a good resource that describes the lifecycle of handles and
> contexts, in easy to understand terms?

Not great, but the TPM spec does have a section on it:
  - Section 15 of 
https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf


They key to know when you get a Handle the high byte determines the
type of handle, when you know the type you can know the lifecycle.

> 
> For example, if I create a primary key and then create a key and seal
> some data, I can keep unsealing the data without reloading the key.
> But if I reboot the computer, I have to create the primary key again
> and reload the key then I can unseal multiple times. So these keys
> get stored in the TPM until reboot it seems.

Correct, they are both transient objects with a high byte of 0x80.
 
> 
> Is there a way to flush them out of the TPM or even list what's
> stored? 

TPM2 Command TPM2_GetCap can show you what's loaded and
TPM2_FlushContext will flush them. Their are matching APIs and tools in
the tpm2-tss and tpm2-tools project. NOTE that when using a resource
manager like tpm2-abrmd or /dev/tpmrm0 that transient objects are
flushed when the application exits or closes the connection with the
resource manager.

> 
> Is there a way to list what's stored, what keys are loaded? 

For example with the tpm2-tools NOT USING A RESOURCE MANAGER:

# create
tpm2 createprimary

# list
tpm2 getcap --tcti=mssim handles-transient
- 0x80000000

# note 0x80 start, so transient
tpm2 flushcontext --tcti=mssim 0x80000000

tpm2 getcap --tcti=mssim handles-transient
# gone

> What about flushing them out without rebooting?

flushcontext

> 
> Thanks!
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tpm2] Re: Lifecycle of handles and contexts

[Tim K]

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

> flushcontext

But when using a resource manager the context gets fushed automatically. Or I can flush it manually. But still, after a flushcontext, I can just tpm2_unseal without loading the key again -- why does that work?

[tpm2] Re: Lifecycle of handles and contexts

[Kenneth Goldman]

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

It depends.  

Windows seems to have a large keystore, so you probably don't have to ever
flush.

Linux in kernel RM manages keys across processes but not within processes,
so you still have to flush.

Why not seal (create) against the primary storage key.

> -----Original Message-----
> From: Tim K <tpm2(a)bitzap.e4ward.com>
> Sent: Monday, July 18, 2022 1:03 PM
> To: tpm2(a)lists.01.org
> Subject: [EXTERNAL] [tpm2] Re: Lifecycle of handles and contexts
> 
> > flushcontext
> 
> But when using a resource manager the context gets fushed automatically.
Or I
> can flush it manually. But still, after a flushcontext, I can just
tpm2_unseal
> without loading the key again -- why does that work?
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5377 bytes --]

[tpm2] Re: Lifecycle of handles and contexts

[Roberts, William C]

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

On Mon, 2022-07-18 at 17:36 +0000, Kenneth Goldman wrote:
> It depends.  
> 
> Windows seems to have a large keystore, so you probably don't have to
> ever
> flush.
> 
> Linux in kernel RM manages keys across processes but not within
> processes,
> so you still have to flush.

This is also how TBS works on Windows.

> 
> Why not seal (create) against the primary storage key.
> 
> > -----Original Message-----
> > From: Tim K <tpm2(a)bitzap.e4ward.com>
> > Sent: Monday, July 18, 2022 1:03 PM
> > To: tpm2(a)lists.01.org
> > Subject: [EXTERNAL] [tpm2] Re: Lifecycle of handles and contexts
> > 
> > > flushcontext
> > 
> > But when using a resource manager the context gets fushed
> > automatically.
> Or I
> > can flush it manually. But still, after a flushcontext, I can just
> tpm2_unseal
> > without loading the key again -- why does that work?

It would help to have specific examples and your environment, very
rarely do you ever need to be concerned with flushcontext calls. The
details below will be very specific to Linux using a resource manager
and the tpm2-tools. If your using the tpm2-tools you use a context
file, so even if the object is flushed, when you call tpm2_unseal -c
<context file> the context is loaded and object is created again. The
context files are only good for that "tpm boot". The same is if your
not using a resource manager, since the tpm2-tools act as a resource
manager. This is so you can use transient objects between commands and
have a resource manager automatically flush the transient resources.
The end goal is that the behavior should appear the same with and
without Resource Managers running in your scripts.

[tpm2] Re: Lifecycle of handles and contexts

[Tim K]

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

> On Mon, 2022-07-18 at 17:36 +0000, Kenneth Goldman wrote:
>
> It would help to have specific examples and your environment, very
> rarely do you ever need to be concerned with flushcontext calls. The
> details below will be very specific to Linux using a resource manager
> and the tpm2-tools. If your using the tpm2-tools you use a context
> file, so even if the object is flushed, when you call tpm2_unseal -c
> <context file> the context is loaded and object is created again. The
> context files are only good for that "tpm boot". The same is if your
> not using a resource manager, since the tpm2-tools act as a resource
> manager. This is so you can use transient objects between commands and
> have a resource manager automatically flush the transient resources.
> The end goal is that the behavior should appear the same with and
> without Resource Managers running in your scripts.

Indeed, I do use tpm2-tools on Ubuntu 20.04 LTS, with the kernel RM (no tpm2-abrmd).
This is exactly the confirmation I was looking for, thank you. I figured it was something like that otherwise I could not explain why it worked.

[tpm2] Re: Lifecycle of handles and contexts

[Kenneth Goldman]

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



>
> On Mon, 2022-07-18 at 17:36 +0000, Kenneth Goldman wrote:
> > It depends.
> >
> > Windows seems to have a large keystore, so you probably don't have to
> > ever flush.
> >
> > Linux in kernel RM manages keys across processes but not within
> > processes, so you still have to flush.
>
> This is also how TBS works on Windows.


Not on my Windows 10.  I just created 32 keys with one process.  Now there are 
32 loaded keys.  OK, the Windows RM swaps them out, but the application never 
sees that.

I don't know what the RM limit is, but it's certainly far more than the TPM 
itself.

getcapability.exe -cap 1 -pr 80000000
32 handles
        80ffffe0
        80ffffe1
        80ffffe2
        80ffffe3
        80ffffe4
        80ffffe5
        80ffffe6
        80ffffe7
        80ffffe8
        80ffffe9
        80ffffea
        80ffffeb
        80ffffec
        80ffffed
        80ffffee
        80ffffef
        80fffff0
        80fffff1
        80fffff2
        80fffff3
        80fffff4
        80fffff5
        80fffff6
        80fffff7
        80fffff8
        80fffff9
        80fffffa
        80fffffb
        80fffffc
        80fffffd
        80fffffe
        80ffffff

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5377 bytes --]

[tpm2] Re: Lifecycle of handles and contexts

[Roberts, William C]

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

On Tue, 2022-07-19 at 22:17 +0000, Kenneth Goldman wrote:
> > On Mon, 2022-07-18 at 17:36 +0000, Kenneth Goldman wrote:
> > > It depends.
> > > 
> > > Windows seems to have a large keystore, so you probably don't
> > > have to
> > > ever flush.
> > > 
> > > Linux in kernel RM manages keys across processes but not within
> > > processes, so you still have to flush.
> > 
> > This is also how TBS works on Windows.
> 
> Not on my Windows 10.  I just created 32 keys with one process.  Now
> there are 
> 32 loaded keys.

Did the process exit? I always thought TBS was spec compliant:
"The RM also monitors connections, and removes table entries and
ContextFlushes leftover sessions
when the caller closes a connection." from Section 2.3.3 of:
https://trustedcomputinggroup.org/wp-content/uploads/TSS_2p0_TAB_ResourceManager_v1p0_r18_04082019_pub.pdf

The table entries include transient handles and their associated
virtual mapping.

> OK, the Windows RM swaps them out, but the application never 
> sees that.
> 
> I don't know what the RM limit is, but it's certainly far more than
> the TPM 
> itself.
> 
> getcapability.exe -cap 1 -pr 80000000
> 32 handles
>         80ffffe0
>         80ffffe1
>         80ffffe2
>         80ffffe3
>         80ffffe4
>         80ffffe5
>         80ffffe6
>         80ffffe7
>         80ffffe8
>         80ffffe9
>         80ffffea
>         80ffffeb
>         80ffffec
>         80ffffed
>         80ffffee
>         80ffffef
>         80fffff0
>         80fffff1
>         80fffff2
>         80fffff3
>         80fffff4
>         80fffff5
>         80fffff6
>         80fffff7
>         80fffff8
>         80fffff9
>         80fffffa
>         80fffffb
>         80fffffc
>         80fffffd
>         80fffffe
>         80ffffff

These look like virtual handles. The spec also states,
"In responses that return handles, these handles MUST be virtualized
before returning the
response to the caller:
 These virtual handles MUST be unique per connection".
I don't think anyone actually makes them unique per connection.

[tpm2] Re: Lifecycle of handles and contexts

[Kenneth Goldman]

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

Windows was with one process not exiting.  

BTW, I do this with scripts by running through the TPM proxy.

AFAIK, only the Intel RM is somewhat TCG compliant.  Even then,
the interface is proprietary to the Intel SAPI.  Neither the Windows
RM nor the Linux RM comply with abrmd or any TCG spec.

Windows, as you see, can create a large number of objects for
each process.

The Linux RM can create 3 objects per process, but many processes
can create 3 objects.


> -----Original Message-----
> From: Roberts, William C <william.c.roberts(a)intel.com>
> Sent: Monday, July 25, 2022 2:57 PM
> To: tpm2(a)bitzap.e4ward.com; Kenneth Goldman <kgoldman(a)us.ibm.com>;
> tpm2(a)lists.01.org
> Subject: [EXTERNAL] Re: [tpm2] Re: Lifecycle of handles and contexts
> 
> On Tue, 2022-07-19 at 22:17 +0000, Kenneth Goldman wrote:
> > > On Mon, 2022-07-18 at 17:36 +0000, Kenneth Goldman wrote:
> > > > It depends.
> > > >
> > > > Windows seems to have a large keystore, so you probably don't have
> > > > to ever flush.
> > > >
> > > > Linux in kernel RM manages keys across processes but not within
> > > > processes, so you still have to flush.
> > >
> > > This is also how TBS works on Windows.
> >
> > Not on my Windows 10.  I just created 32 keys with one process.  Now
> > there are
> > 32 loaded keys.
> 
> Did the process exit? I always thought TBS was spec compliant:
> "The RM also monitors connections, and removes table entries and
> ContextFlushes leftover sessions when the caller closes a connection." from
> Section 2.3.3 of:

> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__trustedcomputinggroup.org_wp-2Dcontent_uploads_TSS-5F2p0-5FTAB-
> 5FResourceManager-5Fv1p0-5Fr18-5F04082019-
> 5Fpub.pdf&d=DwIGaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-
> mlmiA&m=MEqMRdEayqeSC_C_e9M_iXINVdIi7f1gunYT4cXhKxkUh0rqaGP1W
> SR150eCjLz7&s=R6HfwGLoJJyp923npcfsGOh6-VhE_Iha47FJ_5vtGQ4&e=
> 
> The table entries include transient handles and their associated virtual
> mapping.
> 
> > OK, the Windows RM swaps them out, but the application never sees
> > that.
> >
> > I don't know what the RM limit is, but it's certainly far more than
> > the TPM itself.
> >
> > getcapability.exe -cap 1 -pr 80000000
> > 32 handles
> >         80ffffe0
> >         80ffffe1
> >         80ffffe2
> >         80ffffe3
> >         80ffffe4
> >         80ffffe5
> >         80ffffe6
> >         80ffffe7
> >         80ffffe8
> >         80ffffe9
> >         80ffffea
> >         80ffffeb
> >         80ffffec
> >         80ffffed
> >         80ffffee
> >         80ffffef
> >         80fffff0
> >         80fffff1
> >         80fffff2
> >         80fffff3
> >         80fffff4
> >         80fffff5
> >         80fffff6
> >         80fffff7
> >         80fffff8
> >         80fffff9
> >         80fffffa
> >         80fffffb
> >         80fffffc
> >         80fffffd
> >         80fffffe
> >         80ffffff
> 
> These look like virtual handles. The spec also states, "In responses that return
> handles, these handles MUST be virtualized before returning the response to
> the caller:
>  These virtual handles MUST be unique per connection".
> I don't think anyone actually makes them unique per connection.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5377 bytes --]