Re: [PATCH 0/3] Load keys from TPM2 NV Index on IMA keyring

[Ken Goldman <kgold@linux.ibm.com>]

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


On 2/25/2021 4:50 PM, James Bottomley wrote:
> On Thu, 2021-02-25 at 21:32 +0100, Patrick Uiterwijk wrote:
>>
>> Note that if this feature is enabled, users should make sure an NV
>> Index is created with accurate attributes to prevent any other users
>> from writing or deleting the NV Index. Without this precaution, any
>> user who has access to the TPM would be able to write a key to the NV
>> Index and have that key loaded on the IMA trusted keyring.
>>
>> A distro who wants to enable this feature, for example, should ensure
>> that the installer defines the NV Index in all cases, and only fills
>> it if a key was provided by the user.
> 
> This has some problematic security implications:  any member of the tpm
> group (which is pretty much all users if you use the TPM for user space
> secrets or other operations) can read and write NV indexes.  What does
> a distro do if the index is occupied on install (because it could be
> some malicious entity who's put their cert in the index)?
> 
>> It is strongly adviced that any NV Index created for this purpose has
>> at least the policy_delete and policywrite attributes set, together
>> with a non-empty policy. Those flags make sure that the policy (which
>> would be up to them to define) is required to be satisfied to delete
>> or write the index.
> 
> This isn't necessarily good enough.  Unless the index has
> PlatformCreate set, then any member of the tpm group can delete it with
> TPM2_NV_UndefineIndex.  Creating stuff with TPM_NV_PLATFORMCREATE
> attributes is possible, but whoever does must know the platform policy
> or auth, so how would any distro get that if it's non standard (and if
> it is standard then any tpm user can delete the index with
> TPM2_NV_UndefineSpaceSpecial).
> 
> The bottom line is I don't see how this could safely be used by a
> distribution in any standard manner, so why not simply pass the cert in
> on the command line instead?  At least any random user can't then
> compromise the process.

Some ideas on this:

1 - Create the index such that it can be deleted by the platform (pre-OS,
physical presence) but not post-OS.

E.g, create with TPMA_NV_POLICY_DELETE in the owner hierarchy, and with a zero
length policy.  TPM2_Clear will delete it but the owner cannot.

2 - Permit reads with no authorization.

3 - Permit the first write (when the OS is first installed) with no authorization.

E.g., write if written is clear.

If worried about a malicious first write, remove this step and use #5.

4 - Permit writes when a password is supplied locally, the password supplied
during first install.

5 - For remote update, permit a write when given a signed authorization by an
update serve, e.g. a tang server.

E.g., the index policy says "accepts writes signed by this key".  The key
signs an authorization to write a specific new value to NV.
Also:

It is not enough for the application to read the index data.  The application
must read the index metadata (the Name in TCG jargon) to verify that the
index has the correct authorization metadata.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4490 bytes --]