From: Oleksii Moisieiev <Oleksii_Moisieiev(a)epam.com>
Sent: Thursday, June 18, 2020 1:21 PM
To: Struk, Tadeusz <tadeusz.struk(a)intel.com>
Subject: [tpm2] Re: Sharing TPM 2.0 between containers with access policy
Thank you for the answer.
I've done some investigation and found that passing device /dev/tpmrm0 to the
containers will do the job. Also problem with tpm_clear can be solved by
restriction owner access to the tpm. So each container can use keys in TPM but
talk to owner if any changes is needed.
I have another question: According to the documentation - TPM is having unique
endoresement key, embedded to the device during manufacturing. So each
module can be identified by this key.
How can I retrieve this key embedded to the TPM module?
Only the endorsement hierarchy primary seed (EPS) is embedded at manufacturing time. So
Calls to tpm2_createprimary with the proper inputs will yield the same key every time.
to tpm2_createek should create this for you. The calls to tpm2_getekcertificate should
that manufacturer certificate.
Details on this process can be found in this spec:
From: Tadeusz Struk <tadeusz.struk(a)intel.com>
Sent: Friday, June 5, 2020 8:16 PM
To: Oleksii Moisieiev <Oleksii_Moisieiev(a)epam.com>; tpm2(a)lists.01.org
Subject: Re: [tpm2] Sharing TPM 2.0 between containers with access policy
On 6/5/20 12:52 AM, Oleksii Moisieiev wrote:
> Hello all,
> I have an embedded device, with Docker containers based architecture.
> This device is operating by software, installed in separate containers.
> I would like to share TPM2.0 access between this containers with the
> following restrictions:
> 1) Forbid Clear TPM command for the containers;
> 2) Each container should have an access only to the set of keys it owns.
> 3) Each container can create keys, but not overwrite existing keys
> that does not related to this container.
> According to the "TCG TSS 2.0 TAB and Resource Manager Specification"
> - TPM Resource manager doesn't implement access restrictions right now.
I think you could run a separate instance of RM in per container to get
2 & 3. As for 1, this would need to be prevented on a platform configuration level,
like in BIOS or equivalent.