[tpm2] Re: get TPM applications to happily co-exist

[tpm2] Re: get TPM applications to happily co-exist

[Kenneth Goldman]

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

Just my opinion:

The TPM has very few persistent key slots.  They are typically reserved
for early boot when there is no other persistent storage.  Unless you have
a restricted application, like an appliance, try not to use persistent
keys because they may not be available.

Typically, keep your application's key on disk, load it when you need
it, and flush it when you're done or your application exits.

~~

Your understanding is correct - persistent keys are created by the owner,
a higher privileged role that will manage the few (perhaps 7 or less)
key slots.

There are probably complex schemes, forget the owner auth and use
an owner policy specific to each key.  But, unless you have an
appliance / embedded application, you don't control that.

> From: Ted Kim <ted.h.kim(a)oracle.com>
> To: tpm2(a)lists.01.org
> Date: 04/27/2021 12:38 PM
> Subject: [EXTERNAL] [tpm2] get TPM applications to happily co-exist
>
> Folks,
>
> The question has come up about how to get TPM applications to happily
> coexist with minimal coordination.
>
> One issue in the owner hierarchy is we want each application to to be
> able to manage it's own objects but not affect those of the other
> applications.
>
> So for example, we only want application A to be able to evict
> persistent handles owned by that application and not those of another
> application B.
>
> If I understand, tpm2_evictcontrol command, the authorization is on the
> hierarchy and not on the object. Maybe I am thinking about this wrong,
> but is there a way in the authorization to look at some property of the
> object and tell who "owns" it and then figure out if this should be
> allowed or not ?
>
> Otherwise, I think, we end up building some other software which knows
> how to authorize this on the hierarchy and keeps track of who owns what
> and then issues the eviction only when the owner of an object is the
> requester.
>
> Am open to any suggestions.
>
> Thanks,
> -ted
>
> _______________________________________________
> 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: attachment.htm --]
[-- Type: text/html, Size: 3099 bytes --]

[tpm2] Re: get TPM applications to happily co-exist

[Fuchs, Andreas]

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

The TPM specification dictates that the owner/storage hierarchy authorization is the authority over persistent objects.
It makes sense in a way since EvictControl eats up TPM storage resources.

If you wanted isolation in the way you're describing you'd need to patch tpm2-abrmd in order to enforce some kind of access-control to EvictControl beyond the TPM's authorization scheme. But that would be enforced by the tpm2-abrmd daemon, not the TPM itself.

Hope this helps,
Andreas

________________________________________
Von: Ted Kim <ted.h.kim(a)oracle.com>
Gesendet: Dienstag, 27. April 2021 18:38
An: tpm2(a)lists.01.org
Betreff: [tpm2] get TPM applications to happily co-exist

Folks,

The question has come up about how to get TPM applications to happily
coexist with minimal coordination.

One issue in the owner hierarchy is we want each application to to be
able to manage it's own objects but not affect those of the other
applications.

So for example, we only want application A to be able to evict
persistent handles owned by that application and not those of another
application B.

If I understand, tpm2_evictcontrol command, the authorization is on the
hierarchy and not on the object. Maybe I am thinking about this wrong,
but is there a way in the authorization to look at some property of the
object and tell who "owns" it and then figure out if this should be
allowed or not ?

Otherwise, I think, we end up building some other software which knows
how to authorize this on the hierarchy and keeps track of who owns what
and then issues the eviction only when the owner of an object is the
requester.

Am open to any suggestions.

Thanks,
-ted

_______________________________________________
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: get TPM applications to happily co-exist

[Fuchs, Andreas]

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

The tpm2-abrmd as well as the in-kernel resource manager via /dev/tpmrm0 both perform isolation of "connections", i.e. each tss context (on all apis TCTI, SYS; ESYS, FAPI) has an isolated view on the TPM.

That even means if an application opens two ESYS context even they are isolated from each other.
Helps a lot with large multi-module applications.

________________________________________
Von: Ted Kim <ted.h.kim(a)oracle.com>
Gesendet: Mittwoch, 28. April 2021 01:00
An: tpm2(a)lists.01.org
Betreff: [tpm2] Re: get TPM applications to happily co-exist

So it looks like Microsoft has done something to keep TPM-using
applications out of each others way for Windows in "TPM Base Services".

Is someone doing something similar for Linux ?
Is FAPI supposed to eventually do stuff like this ?
Of course, I would rather use the accepted standard tool, instead of
re-inventing the wheel.

Thanks,
-ted

On 4/27/21 9:38 AM, Ted Kim wrote:
> Folks,
>
> The question has come up about how to get TPM applications to happily
> coexist with minimal coordination.
>
> One issue in the owner hierarchy is we want each application to to be
> able to manage it's own objects but not affect those of the other
> applications.
>
> So for example, we only want application A to be able to evict
> persistent handles owned by that application and not those of another
> application B.
>
> If I understand, tpm2_evictcontrol command, the authorization is on
> the hierarchy and not on the object. Maybe I am thinking about this
> wrong, but is there a way in the authorization to look at some
> property of the object and tell who "owns" it and then figure out if
> this should be allowed or not ?
>
> Otherwise, I think, we end up building some other software which knows
> how to authorize this on the hierarchy and keeps track of who owns
> what and then issues the eviction only when the owner of an object is
> the requester.
>
> Am open to any suggestions.
>
> Thanks,
> -ted
>
> _______________________________________________
> 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

--
Ted H. Kim, PhD
ted.h.kim(a)oracle.com
+1 310-258-7515
_______________________________________________
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: get TPM applications to happily co-exist

[Ted Kim]

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

So it looks like Microsoft has done something to keep TPM-using 
applications out of each others way for Windows in "TPM Base Services".

Is someone doing something similar for Linux ?
Is FAPI supposed to eventually do stuff like this ?
Of course, I would rather use the accepted standard tool, instead of 
re-inventing the wheel.

Thanks,
-ted

On 4/27/21 9:38 AM, Ted Kim wrote:
> Folks,
>
> The question has come up about how to get TPM applications to happily 
> coexist with minimal coordination.
>
> One issue in the owner hierarchy is we want each application to to be 
> able to manage it's own objects but not affect those of the other 
> applications.
>
> So for example, we only want application A to be able to evict 
> persistent handles owned by that application and not those of another 
> application B.
>
> If I understand, tpm2_evictcontrol command, the authorization is on 
> the hierarchy and not on the object. Maybe I am thinking about this 
> wrong, but is there a way in the authorization to look at some 
> property of the object and tell who "owns" it and then figure out if 
> this should be allowed or not ?
>
> Otherwise, I think, we end up building some other software which knows 
> how to authorize this on the hierarchy and keeps track of who owns 
> what and then issues the eviction only when the owner of an object is 
> the requester.
>
> Am open to any suggestions.
>
> Thanks,
> -ted
>
> _______________________________________________
> 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

-- 
Ted H. Kim, PhD
ted.h.kim(a)oracle.com
+1 310-258-7515