12

First, I will explain roughly how I plan to use the TPM:

I am using something called tpm-luks which stores a key in both TPM NVRAM and adds the key to one of the LUKS keyslots. The initramfs then decrypts the root LUKS-encrypted partition using the key it gets from the TPM. I also use tpm-luks to seal the key so that the key is released from the TPM NVRAM only when the TPM PCR registers are in a given state (e.g. after a pre-determined bootloader, initramfs, linux etc. have been loaded). TrustedGRUB[2] is used as the bootloader so that it records its own hashes to the TPM PCRs.

I also plan to do remote, unattended upgrades to the system from time to time (e.g. updating the kernel which will also change the hashes of the kernel files etc.). To get around this problem, tpm-luks provides a way to pre-compute the hashes and reseal the key using the new values before the rebooting the machine so that the key can be unlocked again with the new PCR state.

This process currently requires me to enter the TPM owner password each time I do an upgrade and want to add a new key.

My questions are:

  1. Is it okay to use the well-known password of 20 bytes of 0s as the owner/SRK passwords? tpm-luks has the options to use those well-known passwords to perform these operations so that they can be non-interactive. Since the system is locked down, I am assuming no one will be able to exploit this?
  2. If not, would it be feasible to keep the passwords on the encrypted root partition? The system is trusted by the time the root partition is decrypted so it should be safe to store the password there (and access it securely)?
  3. Would it be better to keep the passwords at some other safe location and send them down to the machine if it needs to perform such operations? Not sure if it's any safer than the second option above.
  4. Are there any other better solutions to accomplish the objectives above (non-interactive storage of keys to TPM NVRAM)?
mmtauqir
  • 281
  • 3
  • 9
  • This is why Windows Secure Boot uses PKI... Is it possible for you to go down the Linux Secure Boot route? – billc.cn Jan 11 '16 at 18:44
  • @billc.cn Sure, if it's a feasible solution. I am not knowledgeable enough about what you are suggesting. Any pointers? – mmtauqir Jan 12 '16 at 11:51

1 Answers1

4

Is it okay to use the well-known password of 20 bytes of 0s as the owner/SRK passwords? tpm-luks has the options to use those well-known passwords to perform these operations so that they can be non-interactive. Since the system is locked down, I am assuming no one will be able to exploit this?

If you leave the owner and password as default or well-known values you are opening the door to circumventing the entire secure boot process. This is more of a concern in embedded systems out in the field that are meant to be tamper resistant (tampering in this case causes them to either fail to operate or fall into a functionally limited fail-safe mode).

If you use well known owner/password anyone with the experience or knowledge could change the underlying OS image/hardware configuration, update TPM PCR values and still access the file-system keys, bypassing whatever security/integrity measures you are putting in place.

If not, would it be feasible to keep the passwords on the encrypted root partition? The system is trusted by the time the root partition is decrypted so it should be safe to store the password there (and access it securely)?

Sure, I can see this working, although, once the system is booted and deemed 'trusted' you're still susceptible to someone picking up the keys which would then permit them to remove the drive from the system and decrypting it. So, sure, it's safe to store it there ... while it's encrypted, but post-boot it's a risk. (This could ultimately result in backdoors installed on 'trusted systems')

Would it be better to keep the passwords at some other safe location and send them down to the machine if it needs to perform such operations? Not sure if it's any safer than the second option above.

The TPM is literally the best place for you to store your keys.

Are there any other better solutions to accomplish the objectives above (non-interactive storage of keys to TPM NVRAM)?

Sure. It sound like you're looking at complicated solutions for a single, tooling problem: your tools don't let you automate ownership/setting passwords.

I would probably checkout the trousers code repo, get it built and sanity test it, then modify the tpm_takeownership tool to add a non-interactive owner/password prompt option then use that custom binary during your upgrade process.

Whome
  • 1,231
  • 11
  • 21
  • 2
    great detailed answer. Can you explain your "If you use well known owner/password anyone with the experience or knowledge could change the underlying OS image/hardware configuration, update TPM PCR values and still access the file-system keys"? If you seal keys, are they not bound to whichever PCRs you chose? Any change in BIOS, settings, bootloader, or anything else would result in changed PCRs, leaving the sealed data inaccessible, would it not? – deitch Apr 03 '16 at 13:23
  • 1
    @whome Could you answer the previous comment's questions, please? – Melab Jul 01 '17 at 15:11
  • 4
    *If you use well known owner/password anyone with the experience or knowledge could change the underlying OS image/hardware configuration, update TPM PCR values and still access the file-system keys...* That's not correct. The whole point of sealing data to a TPM is to prevent unsealing in the event that PCR measurements that were sealed against change. So if I seal a key to measurements of the hardware, bootloader, kernel, etc, and you modify a piece of that and attempt to boot, even knowing that the owner password is the well-known secret, the TPM will not unseal it for you. – krb686 Nov 17 '17 at 22:36
  • I believe the purpose of the well-known key is for situations where the TPM contains data which is confidential, rather than just used for verification. If someone were to extract the TPM, they could likely guess the configuration necessary to put the PCRs in the correct state to unseal it. Using a secret key just provides an additional layer of protection, implemented in secure hardware. – guest Nov 19 '17 at 06:19