4

Lets say I create a self-signed certificate in Powershell like this:

New-SelfSignedCertificate -Provider "Microsoft Platform Crypto Provider" -Subject "CN=foobar" -KeyExportPolicy NonExportable -KeyAlgorithm RSA  -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -NotAfter $((Get-Date).AddYears(10))

The intended use of the certificate is code-signing of powershell scripts.

Because of the fact that the Provider is MS platform crypto provider the keys will be generated by the Trusted Platform Module (TPM) Chip embedded in my motherboard.

The private key is thus now stored in the "black-box" TPM. So is there any need to wrap / password-protect the private key?

joop s
  • 107
  • 1
  • 2
  • 9
  • At first glance I would agree with you. But you need to share some more details about the expected usage of the newly created certificate. Is it just for some internal testing? What if someone gets access to the machine, is that a problem you need to address? – Mötz Dec 24 '18 at 09:03
  • If someone gains access to the machine my secrets will be lost anyway I suppose? – joop s Dec 24 '18 at 09:38
  • It depends on how you use/store the password. If you plan on something like using the certificate for CI/CD pipelines, you will at some point have to store a secret somewhere and if you do that on the machine it really doesn't matter. So, what purpose is the certificate intended for and how big risk would you say it purposes if the certificate is stolen, including the likelihood of that to happen... – Mötz Dec 24 '18 at 11:56

1 Answers1

3

Any key created by a TPM is already wrapped, either by:

  • The storage root key for TPM 1.2, or
  • One of the primary keys indicated as the key's parent for TPM 2

So the key is wrapped by one of the root keys at the time of creating the key, and there is nothing special you have to do to make it happen. In fact, you cannot make it not happen.

The root keys themselves are guaranteed by the TPM spec to never leave the TPM. If you want to guarantee that your newly generated key will never leave the TPM either, make it non-migrateable.

In addition, you can also make any of the aforementioned keys password-protected. Whether or not you do that depends on your specific requirements. Keep in mind however that the TPM spec is not focused on protecting against physical attacks, so if you lose physical access to your machine you should probably consider it compromised.

mnistic
  • 10,866
  • 2
  • 19
  • 33
  • Can you give any reference please? – joop s Dec 24 '18 at 18:21
  • 1
    Well, other than the TPM spec, there is not much else out there. For example, for TPM 1.2: https://trustedcomputinggroup.org/resource/tpm-main-specification/ – mnistic Dec 24 '18 at 19:03
  • Take a look at Part 3: Commands, section 10.4: `TPM_CreateWrapKey` which is what is used to generate a key with the TPM, step 16: "Encrypt the private portions of the wrappedKey structure using the key in parentHandle" – mnistic Dec 24 '18 at 19:03
  • Note that I made the answer a little simplistic, as you can have a whole hierarchy of keys in between the SRK and your new key, but in practice this rarely happens. – mnistic Dec 24 '18 at 19:06
  • And, `Tspi_Key_CreateKey` invokes `TPM_CreateWrapKey`: https://linux.die.net/man/3/tspi_key_createkey – mnistic Dec 24 '18 at 19:12
  • I couldn't find a powershell reference, but they are limited by the TPM spec too, it's not like they could have invented a new TPM command that's not wrapping the key... – mnistic Dec 24 '18 at 19:15
  • https://learn.microsoft.com/en-us/powershell/module/pkiclient/new-selfsignedcertificate?view=win10-ps#examples Example 6 says roughly the same. – joop s Dec 25 '18 at 00:32