| Message ID | 1540193596.3202.7.camel@HansenPartnership.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add integrity and security to TPM2 transactions | expand |
On 10/22/2018 3:33 AM, James Bottomley wrote: > By now, everybody knows we have a problem with the TPM2_RS_PW easy > button on TPM2 in that transactions on the TPM bus can be intercepted > and altered. The way to fix this is to use real sessions for HMAC > capabilities to ensure integrity and to use parameter and response > encryption to ensure confidentiality of the data flowing over the TPM > bus. Does this design assume that there was at time zero no monitoring? This would permit some shared secret to be established. Or does it assume that the interception may have been present from the first boot? If so, how is the first shared secret established. Salting using the EK is the usual method, but this requires walking the EK certificate chain and embedding the TPM vendor CA certificates in the kernel. > This patch series is about adding a simple API which can ensure the > above properties as a layered addition to the existing TPM handling > code. This series now includes protections for PCR extend, getting > random numbers from the TPM and data sealing and unsealing. It > therefore eliminates all uses of TPM2_RS_PW in the kernel and adds > encryption protection to sensitive data flowing into and out of the > TPM. > > In the third version I added data sealing and unsealing protection, > apart from one API based problem which means that the way trusted keys > were protected it's not currently possible to HMAC protect an authority > that comes with a policy, so the API will have to be extended to fix > that case TPM 2.0 observations (questioning 'not possible'): 1 - Any policy that requires a password (policypassword) can substitute an HMAC (policyauthvalue) at the callers discretion. They result in the same policy digest. 2 - Any command can be HMAC protected, even one like pcrread that does not require authorization. Start an HMAC session and specify audit. Of course, a shared secret has to be used, either a bind or salted session. 3 - If the command is already using a policy session, but does not require a password, I believe that the same technique #2 can be used - specify audit with that policy session. I've tested #3 with bind but not salt. I can test if there's interest. > In this fourth version, I tidy up some of the code and add more > security features, the most notable is that we now calculate the NULL > seed name and compare our calculation to the value returned in > TPM2_ReadPublic, which means we now can't be spoofed. This version > also gives a sysfs variable for the null seed which userspace can use > to run a key certification operation to prove that the TPM was always > secure when communicating with the kernel. > > I've verified this using the test suite in the last patch on a VM > connected to a tpm2 emulator. I also instrumented the emulator to make > sure the sensitive data was properly encrypted.
On Mon, 2018-10-22 at 09:53 -0400, Ken Goldman wrote: > On 10/22/2018 3:33 AM, James Bottomley wrote: > > By now, everybody knows we have a problem with the TPM2_RS_PW easy > > button on TPM2 in that transactions on the TPM bus can be > > intercepted and altered. The way to fix this is to use real > > sessions for HMAC capabilities to ensure integrity and to use > > parameter and response encryption to ensure confidentiality of the > > data flowing over the TPM bus. > > Does this design assume that there was at time zero no monitoring? > This would permit some shared secret to be established. > > Or does it assume that the interception may have been present from > the first boot? If so, how is the first shared secret established. > Salting using the EK is the usual method, but this requires walking > the EK certificate chain and embedding the TPM vendor CA > certificates in the kernel. The design establishes the shared secret at start of day using an EC derived key from the null seed. This can obviously be spoofed by a TPM Genie running before the system was rebooted. However, the computed key name is exposed to user space and TPM2_Certify will fail when userspace checks the null seed so you will know after the fact whether the communication channel established on boot was secure or not. It is possible to use either the EPS or SPS if we pass in the public points as kernel parameters but this is getting rather complicated for casual users. > > This patch series is about adding a simple API which can ensure the > > above properties as a layered addition to the existing TPM handling > > code. This series now includes protections for PCR extend, getting > > random numbers from the TPM and data sealing and unsealing. It > > therefore eliminates all uses of TPM2_RS_PW in the kernel and adds > > encryption protection to sensitive data flowing into and out of the > > TPM. > > > > In the third version I added data sealing and unsealing protection, > > apart from one API based problem which means that the way trusted > > keys were protected it's not currently possible to HMAC protect an > > authority that comes with a policy, so the API will have to be > > extended to fix that case > > TPM 2.0 observations (questioning 'not possible'): Actually, let me correct that: not possible with the way policy based trusted keys API works because it expects you to pass in a policy session handle. The way to fix this is to fix the API to pass in the actual policy sequence instead of the commands, but that's long term. > 1 - Any policy that requires a password (policypassword) can > substitute > an HMAC (policyauthvalue) at the callers discretion. They result > in the same policy digest. Right but this requires the co-operation of the policy handle creator, so it's an API change. > 2 - Any command can be HMAC protected, even one like pcrread that > does not require authorization. Start an HMAC session and specify > audit Of course, a shared secret has to be used, either a bind or > salted session. Right, so if we create the session, we can then set it up to use a salted session, but we don't create it under the current API. > 3 - If the command is already using a policy session, but does not > require a password, I believe that the same technique #2 can be > used - specify audit with that policy session. > > I've tested #3 with bind but not salt. I can test if there's > interest. I think the API is going to have to change, so if we're looking at a new API, we should set it up to do the right thing with policy anyway. It turns out to be quite easy as I found out when Huawei patched the openssl_tpm2_engine to add policy to keys. James > > In this fourth version, I tidy up some of the code and add more > > security features, the most notable is that we now calculate the > > NULL seed name and compare our calculation to the value returned in > > TPM2_ReadPublic, which means we now can't be spoofed. This version > > also gives a sysfs variable for the null seed which userspace can > > use to run a key certification operation to prove that the TPM was > > always secure when communicating with the kernel. > > > > I've verified this using the test suite in the last patch on a VM > > connected to a tpm2 emulator. I also instrumented the emulator to > > make sure the sensitive data was properly encrypted. > >
On 10/22/2018 10:18 AM, James Bottomley wrote: >> 1 - Any policy that requires a password (policypassword) can >> substitute >> an HMAC (policyauthvalue) at the callers discretion. They result >> in the same policy digest. > Right but this requires the co-operation of the policy handle creator, > so it's an API change. > In case it wasn't clear: The choice is not made at the time the policy is calculated, nor is it made at startauthsession (when the policy is created). The choice is made when the policy is being satisfied. policypassword tells the TPM to expect a plaintext password, while policyauthvalue tells the TPM to expect an HMAC. It's subtle that either policy command results in the same policy digest.
On Mon, 2018-10-22 at 11:50 -0400, Ken Goldman wrote: > On 10/22/2018 10:18 AM, James Bottomley wrote: > > > 1 - Any policy that requires a password (policypassword) can > > > substitute > > > an HMAC (policyauthvalue) at the callers discretion. They result > > > in the same policy digest. > > > > Right but this requires the co-operation of the policy handle > > creator, so it's an API change. > > > > In case it wasn't clear: The choice is not made at the time the > policy is calculated, nor is it made at startauthsession (when > the policy is created). > > The choice is made when the policy is being satisfied. > > policypassword tells the TPM to expect a plaintext password, while > policyauthvalue tells the TPM to expect an HMAC. > > It's subtle that either policy command results in the same policy > digest. I understand, but the API just has a policy handle from a fully constructed policy passed in. There's no way to deconstruct this even to know if it has auth requirements and what type. To get that info we have to see the policy commands that go into building up the policy session ... this means the API needs to change. James
I would consider sending first a patch set that would iterate the existing session stuff to be ready for this i.e. merge in two iterations (emphasis on the word "consider"). We can probably merge the groundwork quite fast. /Jarkko On Mon, 22 Oct 2018, James Bottomley wrote: > By now, everybody knows we have a problem with the TPM2_RS_PW easy > button on TPM2 in that transactions on the TPM bus can be intercepted > and altered. The way to fix this is to use real sessions for HMAC > capabilities to ensure integrity and to use parameter and response > encryption to ensure confidentiality of the data flowing over the TPM > bus. > > This patch series is about adding a simple API which can ensure the > above properties as a layered addition to the existing TPM handling > code. This series now includes protections for PCR extend, getting > random numbers from the TPM and data sealing and unsealing. It > therefore eliminates all uses of TPM2_RS_PW in the kernel and adds > encryption protection to sensitive data flowing into and out of the > TPM. > > In the third version I added data sealing and unsealing protection, > apart from one API based problem which means that the way trusted keys > were protected it's not currently possible to HMAC protect an authority > that comes with a policy, so the API will have to be extended to fix > that case > > In this fourth version, I tidy up some of the code and add more > security features, the most notable is that we now calculate the NULL > seed name and compare our calculation to the value returned in > TPM2_ReadPublic, which means we now can't be spoofed. This version > also gives a sysfs variable for the null seed which userspace can use > to run a key certification operation to prove that the TPM was always > secure when communicating with the kernel. > > I've verified this using the test suite in the last patch on a VM > connected to a tpm2 emulator. I also instrumented the emulator to make > sure the sensitive data was properly encrypted. > > James > > --- > > > James Bottomley (7): > tpm-buf: create new functions for handling TPM buffers > tpm2-sessions: Add full HMAC and encrypt/decrypt session handling > tpm2: add hmac checks to tpm2_pcr_extend() > tpm2: add session encryption protection to tpm2_get_random() > trusted keys: Add session encryption protection to the seal/unseal > path > tpm: add the null key name as a tpm2 sysfs variable > tpm2-sessions: NOT FOR COMMITTING add sessions testing > > drivers/char/tpm/Kconfig | 3 + > drivers/char/tpm/Makefile | 3 +- > drivers/char/tpm/tpm-buf.c | 191 ++++++ > drivers/char/tpm/tpm-chip.c | 1 + > drivers/char/tpm/tpm-sysfs.c | 27 +- > drivers/char/tpm/tpm.h | 129 ++-- > drivers/char/tpm/tpm2-cmd.c | 248 ++++--- > drivers/char/tpm/tpm2-sessions-test.c | 360 ++++++++++ > drivers/char/tpm/tpm2-sessions.c | 1188 +++++++++++++++++++++++++++++++++ > drivers/char/tpm/tpm2-sessions.h | 57 ++ > 10 files changed, 2027 insertions(+), 180 deletions(-) > create mode 100644 drivers/char/tpm/tpm-buf.c > create mode 100644 drivers/char/tpm/tpm2-sessions-test.c > create mode 100644 drivers/char/tpm/tpm2-sessions.c > create mode 100644 drivers/char/tpm/tpm2-sessions.h > > -- > 2.16.4 > >
On Mon, 22 Oct 2018, Ken Goldman wrote: > Does this design assume that there was at time zero no monitoring? > This would permit some shared secret to be established. > > Or does it assume that the interception may have been present from > the first boot? If so, how is the first shared secret established. > Salting using the EK is the usual method, but this requires walking the EK > certificate chain and embedding the TPM vendor CA certificates in the kernel. Kernel gets the public portion EK and uses its own key pair in its own end so everything should be good, right? /Jarkko
On Mon, 22 Oct 2018, James Bottomley wrote: > On Mon, 2018-10-22 at 09:53 -0400, Ken Goldman wrote: >> On 10/22/2018 3:33 AM, James Bottomley wrote: >>> By now, everybody knows we have a problem with the TPM2_RS_PW easy >>> button on TPM2 in that transactions on the TPM bus can be >>> intercepted and altered. The way to fix this is to use real >>> sessions for HMAC capabilities to ensure integrity and to use >>> parameter and response encryption to ensure confidentiality of the >>> data flowing over the TPM bus. >> >> Does this design assume that there was at time zero no monitoring? >> This would permit some shared secret to be established. >> >> Or does it assume that the interception may have been present from >> the first boot? If so, how is the first shared secret established. >> Salting using the EK is the usual method, but this requires walking >> the EK certificate chain and embedding the TPM vendor CA >> certificates in the kernel. > > The design establishes the shared secret at start of day using an EC > derived key from the null seed. This can obviously be spoofed by a TPM > Genie running before the system was rebooted. However, the computed > key name is exposed to user space and TPM2_Certify will fail when > userspace checks the null seed so you will know after the fact whether > the communication channel established on boot was secure or not. > > It is possible to use either the EPS or SPS if we pass in the public > points as kernel parameters but this is getting rather complicated for > casual users. Where was the code that exposes it to the user space? /Jarkko
On Wed, 2018-10-24 at 03:06 +0300, Jarkko Sakkinen wrote: > On Mon, 22 Oct 2018, Ken Goldman wrote: > > Does this design assume that there was at time zero no monitoring? > > This would permit some shared secret to be established. > > > > Or does it assume that the interception may have been present from > > the first boot? If so, how is the first shared secret established. > > Salting using the EK is the usual method, but this requires walking > > the EK certificate chain and embedding the TPM vendor CA > > certificates in the kernel. > > Kernel gets the public portion EK and uses its own key pair in its > own end so everything should be good, right? Only if we pass it in. The kernel can't run an X509 proof on the EK certificate, which is how you verify the EK: Usually the X509 cert is RSA, and for speed and efficiency we're salting with Elliptic Curve keys, so we'd have to derive the RSA EK primary (which can take up to 60 seconds), verify the same public key as the cert and then chain up to the manufacturer. Then we'd have to use the RSA keys (so a lot more code) because we can't trust the TPM not to lie about the RSA public key but then substitute it's own EC primary. We really don't want to be trying to do all that on boot. James
On Wed, 2018-10-24 at 03:13 +0300, Jarkko Sakkinen wrote: > On Mon, 22 Oct 2018, James Bottomley wrote: > > On Mon, 2018-10-22 at 09:53 -0400, Ken Goldman wrote: > > > On 10/22/2018 3:33 AM, James Bottomley wrote: > > > > By now, everybody knows we have a problem with the TPM2_RS_PW > > > > easy button on TPM2 in that transactions on the TPM bus can be > > > > intercepted and altered. The way to fix this is to use real > > > > sessions for HMAC capabilities to ensure integrity and to use > > > > parameter and response encryption to ensure confidentiality of > > > > the data flowing over the TPM bus. > > > > > > Does this design assume that there was at time zero no > > > monitoring? This would permit some shared secret to be > > > established. > > > > > > Or does it assume that the interception may have been present > > > from the first boot? If so, how is the first shared secret > > > established. Salting using the EK is the usual method, but this > > > requires walking the EK certificate chain and embedding the TPM > > > vendor CA certificates in the kernel. > > > > The design establishes the shared secret at start of day using an > > EC derived key from the null seed. This can obviously be spoofed > > by a TPM Genie running before the system was rebooted. However, > > the computed key name is exposed to user space and TPM2_Certify > > will fail when userspace checks the null seed so you will know > > after the fact whether the communication channel established on > > boot was secure or not. > > > > It is possible to use either the EPS or SPS if we pass in the > > public points as kernel parameters but this is getting rather > > complicated for casual users. > > Where was the code that exposes it to the user space? It's patch 6/7. It exposes the null ec primary name in sysfs: jejb@jarvis~> cat /sys/class/tpm0/tpm/null_name 000ba4fa35ecfbf7c85e5407d07edc27f6a522c8b1a011bcb68c60b27baf21f9d9ec The key certification gives you back a signed copy of the name which you can verify against this. James
On Wed, 2018-10-24 at 02:51 +0300, Jarkko Sakkinen wrote: > I would consider sending first a patch set that would iterate the > existing session stuff to be ready for this i.e. merge in two > iterations (emphasis on the word "consider"). We can probably merge > the groundwork quite fast. I realise we're going to have merge conflicts on the later ones, so why don't we do this: I'll still send as one series, but you apply the ones you think are precursors and I'll rebase and resend the rest? James
On Wed, 24 Oct 2018, James Bottomley wrote: > On Wed, 2018-10-24 at 03:13 +0300, Jarkko Sakkinen wrote: >> On Mon, 22 Oct 2018, James Bottomley wrote: >>> On Mon, 2018-10-22 at 09:53 -0400, Ken Goldman wrote: >>>> On 10/22/2018 3:33 AM, James Bottomley wrote: >>>>> By now, everybody knows we have a problem with the TPM2_RS_PW >>>>> easy button on TPM2 in that transactions on the TPM bus can be >>>>> intercepted and altered. The way to fix this is to use real >>>>> sessions for HMAC capabilities to ensure integrity and to use >>>>> parameter and response encryption to ensure confidentiality of >>>>> the data flowing over the TPM bus. >>>> >>>> Does this design assume that there was at time zero no >>>> monitoring? This would permit some shared secret to be >>>> established. >>>> >>>> Or does it assume that the interception may have been present >>>> from the first boot? If so, how is the first shared secret >>>> established. Salting using the EK is the usual method, but this >>>> requires walking the EK certificate chain and embedding the TPM >>>> vendor CA certificates in the kernel. >>> >>> The design establishes the shared secret at start of day using an >>> EC derived key from the null seed. This can obviously be spoofed >>> by a TPM Genie running before the system was rebooted. However, >>> the computed key name is exposed to user space and TPM2_Certify >>> will fail when userspace checks the null seed so you will know >>> after the fact whether the communication channel established on >>> boot was secure or not. >>> >>> It is possible to use either the EPS or SPS if we pass in the >>> public points as kernel parameters but this is getting rather >>> complicated for casual users. >> >> Where was the code that exposes it to the user space? > > It's patch 6/7. It exposes the null ec primary name in sysfs: > > jejb@jarvis~> cat /sys/class/tpm0/tpm/null_name > 000ba4fa35ecfbf7c85e5407d07edc27f6a522c8b1a011bcb68c60b27baf21f9d9ec > > The key certification gives you back a signed copy of the name which > you can verify against this. > > James I missed 6/7, sorry. Do you have an example user space program for doing the verification by using this file? /Jarkko
On Wed, 24 Oct 2018, James Bottomley wrote: > On Wed, 2018-10-24 at 02:51 +0300, Jarkko Sakkinen wrote: >> I would consider sending first a patch set that would iterate the >> existing session stuff to be ready for this i.e. merge in two >> iterations (emphasis on the word "consider"). We can probably merge >> the groundwork quite fast. > > I realise we're going to have merge conflicts on the later ones, so why > don't we do this: I'll still send as one series, but you apply the ones > you think are precursors and I'll rebase and resend the rest? > > James Works for me and now I think after yesterdays dicussions etc. that this should be merged as one series. /Jarkko
On 10/24/2018 3:34 AM, James Bottomley wrote: > so we'd have to derive the RSA EK primary (which can take up to > 60 seconds) Just FYI: The TPM vendors seem to be caching the two standard EKs during manufacturing. When the TPM detects the EK template during createprimary, it quickly returns the cached value. This optimization is not required, but it is common.
By now, everybody knows we have a problem with the TPM2_RS_PW easy button on TPM2 in that transactions on the TPM bus can be intercepted and altered. The way to fix this is to use real sessions for HMAC capabilities to ensure integrity and to use parameter and response encryption to ensure confidentiality of the data flowing over the TPM bus. This patch series is about adding a simple API which can ensure the above properties as a layered addition to the existing TPM handling code. This series now includes protections for PCR extend, getting random numbers from the TPM and data sealing and unsealing. It therefore eliminates all uses of TPM2_RS_PW in the kernel and adds encryption protection to sensitive data flowing into and out of the TPM. In the third version I added data sealing and unsealing protection, apart from one API based problem which means that the way trusted keys were protected it's not currently possible to HMAC protect an authority that comes with a policy, so the API will have to be extended to fix that case In this fourth version, I tidy up some of the code and add more security features, the most notable is that we now calculate the NULL seed name and compare our calculation to the value returned in TPM2_ReadPublic, which means we now can't be spoofed. This version also gives a sysfs variable for the null seed which userspace can use to run a key certification operation to prove that the TPM was always secure when communicating with the kernel. I've verified this using the test suite in the last patch on a VM connected to a tpm2 emulator. I also instrumented the emulator to make sure the sensitive data was properly encrypted. James --- James Bottomley (7): tpm-buf: create new functions for handling TPM buffers tpm2-sessions: Add full HMAC and encrypt/decrypt session handling tpm2: add hmac checks to tpm2_pcr_extend() tpm2: add session encryption protection to tpm2_get_random() trusted keys: Add session encryption protection to the seal/unseal path tpm: add the null key name as a tpm2 sysfs variable tpm2-sessions: NOT FOR COMMITTING add sessions testing drivers/char/tpm/Kconfig | 3 + drivers/char/tpm/Makefile | 3 +- drivers/char/tpm/tpm-buf.c | 191 ++++++ drivers/char/tpm/tpm-chip.c | 1 + drivers/char/tpm/tpm-sysfs.c | 27 +- drivers/char/tpm/tpm.h | 129 ++-- drivers/char/tpm/tpm2-cmd.c | 248 ++++--- drivers/char/tpm/tpm2-sessions-test.c | 360 ++++++++++ drivers/char/tpm/tpm2-sessions.c | 1188 +++++++++++++++++++++++++++++++++ drivers/char/tpm/tpm2-sessions.h | 57 ++ 10 files changed, 2027 insertions(+), 180 deletions(-) create mode 100644 drivers/char/tpm/tpm-buf.c create mode 100644 drivers/char/tpm/tpm2-sessions-test.c create mode 100644 drivers/char/tpm/tpm2-sessions.c create mode 100644 drivers/char/tpm/tpm2-sessions.h