linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
@ 2018-11-19 17:34 James Bottomley
  2018-11-19 20:05 ` Jason Gunthorpe
                   ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: James Bottomley @ 2018-11-19 17:34 UTC (permalink / raw)
  To: linux-integrity, linux-security-module
  Cc: Jarkko Sakkinen, monty.wiseman, Monty Wiseman, Matthew Garrett

Hi All,

I took the action at the Edinburgh meeting to document this, so the
attached is what I'm proposing (I'll also add this to my patch set
doing the implementation to live in Documentation/security/tpm/tpm-
security.rst).  Please could you give it a read; one thing that came
out of the Edinburgh meeting was that people with too much exposure to
TPM crypto acquire twists in their brains which mean stuff which seems
obvious to them isn't to anyone else, so I need external reviewers to
assure me that the document is understandable by non-TPM security
people.

Once this passes the understandability bar, I'll pass it on to
Microsoft and TianoCore/UEFI as our preferred mechanism for thwarting
interposer attacks.

Thanks,

James

---

TPM Security
============

The object of this document is to describe how we make the kernel's
use of the TPM reasonably robust in the face of external snooping and
packet alteration attacks.  The current security document is for TPM
2.0.

Introduction
------------

The TPM is usually a discrete chip attached to a PC via some type of
low bandwidth bus.  There are exceptions to this such as the Intel
PTT, which is a software TPM running inside a software environment
close to the CPU, which are subject to different attacks, but right at
the moment, most hardened security environments require a discrete
hardware TPM, which is the use case discussed here.

Snooping and Alteration Attacks against the bus
-----------------------------------------------

The current state of the art for snooping the TPM Genie hardware
interposer https://www.nccgroup.trust/us/our-research/tpm-genie/ which
is a simple external device that can be installed in a couple of
seconds on any system or laptop.  However, the next phase of research
seems to be hacking existing devices on the bus to act as interposers,
so the fact that the attacker requires physical access for a few
seconds might evaporate.  However, the goal of this document is to
protect TPM secrets and integrity as far as we are able in this
environment and to try to insure that if we can't prevent the attack
then at least we can detect it.

Unfortunately, most of the TPM functionality, including the hardware
reset capability can be controlled by an attacker who has access to
the bus, so we'll discuss some of the disruption possibilities below.

Measurement (PCR) Integrity
---------------------------

Since the attacker can send their own commands to the TPM, they can
send arbitrary PCR extends and thus disrupt the measurement system,
which would be an annoying denial of service attack.  However, there
are two, more serious, classes of attack aimed at entities sealed to
trust measurements.

1. The attacker could intercept all PCR extends coming from the system
   and completely substitute their own values, producing a replay of
   an untampered state that would cause PCR measurements to attest to
   a trusted state and release secrets

2. At some point in time the attacker could reset the TPM, clearing
   the PCRs and then send down their own measurements which would
   effectively overwrite the boot time measurements the TPM has
   already done.

The first can be thwarted by always doing HMAC protection of the PCR
extend and read command meaning measurement values cannot be
substituted without producing a detectable HMAC failure in the
response.  However, the second can only really be detected by relying
on some sort of mechanism for protection which would change over TPM
reset.

Secrets Guarding
----------------

Certain information passing in and out of the TPM, such as key sealing
and private key import and random number generation, is vulnerable to
interception which HMAC protection alone cannot protect, so for these
types of command we must also employ request and response encryption
to prevent the loss of secret information.

Establishing Initial Trust with the TPM
---------------------------------------

In order to provide security from the beginning, an initial shared or
asymmetric secret must be established which must also be unknown to
the attacker.  The most obvious avenues for this are the endorsement
and storage seeds, which can be used to derive asymmetric keys.
However, using these keys is difficult because the only way to pass
them into the kernel would be on the command line, which requires
extensive support in the boot system, and there's no guarantee that
either hierarchy would not have some type of authorization.

The mechanism chosen for the Linux Kernel is to derive the primary
elliptic curve key from the null seed using the standard storage seed
parameters.  The null seed has two advantages: firstly the hierarchy
physically cannot have an authorization, so we are always able to use
it and secondly, the null seed changes across TPM resets, meaning if
we establish trust on the null seed at start of day, all sessions
salted with the derived key will fail if the TPM is reset and the seed
changes.

Obviously using the null seed without any other prior shared secrets,
we have to create and read the initial public key which could, of
course, be intercepted and substituted by the bus interposer.
However, the TPM has a key certification mechanism (using the EK
endorsement certificate, creating an attestation identity key and
certifying the null seed primary with that key) which is too complex
to run within the kernel, so we keep a copy of the null primary key
name, which is what is certified so user-space can run the full
certification when it boots.  The definitive guarantee here is that if
the null primary key certifies correctly, you know all your TPM
transactions since start of day were secure and if it doesn't, you
know there's an interposer on your system (and that any secret used
during boot may have been leaked).

Stacking Trust
--------------

In the current null primary scenario, the TPM must be completely
cleared before handing it on to the next consumer.  However the kernel
hands to user-space the name of the derived null seed key which can
then be verified by certification in user-space.  Therefore, this chain
of name handoff can be used between the various boot components as
well (via an unspecified mechanism).  For instance, grub could use the
null seed scheme for security and hand the name off to the kernel in
the boot area.  The kernel could make its own derivation of the key
and the name and know definitively that if they differ from the handed
off version that tampering has occurred.  Thus it becomes possible to
chain arbitrary boot components together (UEFI to grub to kernel) via
the name handoff provided each successive component knows how to
collect the name and verifies it against its derived key.

Session Properties
------------------

All TPM commands the kernel uses allow sessions.  HMAC sessions may be
used to check the integrity of requests and responses and decrypt and
encrypt flags may be used to shield parameters and responses.  The
HMAC and encryption keys are usually derived from the shared
authorization secret, but for a lot of kernel operations that is well
known (and usually empty).  Thus, every HMAC session used by the
kernel must be created using the null primary key as the salt key
which thus provides a cryptographic input into the session key
derivation.  Thus, the kernel creates the null primary key once (as a
volatile TPM handle) and keeps it around in the kernel TPM space for
every in-kernel use of the TPM.  Currently, because of a lack of
de-gapping in the in-kernel resource manager, the session must be
created and destroyed for each operation, but, in future, a single
session may also be reused for the in-kernel HMAC, encryption and
decryption sessions.

Protection Types
----------------

For every in-kernel operation we use null primary salted HMAC to
protect the integrity.  Additionally, we use parameter encryption to
protect key sealing and parameter decryption to protect key unsealing
and random number generation.

Null Primary Key Certification in Userspace
===========================================

Every TPM comes shipped with a couple of X.509 certificates for the
primary endorsement key.  This document assumes that the Elliptic
Curve version of the certificate exists at 01C00002, but will work
equally well with the RSA certificate (at 01C00001).

The first step in the certification is primary creation using the
template from the `TCG EK Credential Profile`_ which allows comparison
of the generated primary key against the one in the certificate (the
public key must match).  Note that generation of the EK primary
requires the EK hierarchy password, but a pre-generated version of the
EC primary should exist at 81010002 and a TPM2_ReadPublic() may be
performed on this without needing the key authority.  Next, the
certificate itself must be verified to chain back to the manufacturer
root (which should be published on the manufacturer website).  Once
this is done, the generated EK primary key may now be used to run an
attestation on the null seed.  The specific problem here is that the
EK primary is not a signing key so cannot on its own be used to sign
the key certification, hence the complex process below.

Note: this process is a simplified abbreviation of the usual privacy
CA based attestation process.  The assumption here is that the
attestation is done by the TPM owner who thus has access to only the
owner hierarchy.  The owner creates an external public/private key
pair (assume elliptic curve in this case) and wraps the private key
for import using an inner wrapping process and parented to the EC
derived storage primary.  The TPM2_Import() is done using a parameter
decryption HMAC session salted to the EK primary (which also does not
require the EK key authority) meaning that the inner wrapping key is
the encrypted parameter and thus the TPM will not be able to perform
the import unless is possesses the certified EK so if the command
succeeds and the HMAC verifies on return we know we have a loadable
copy of the private key only for the certified TPM.  This key is now
loaded into the TPM and the Storage primary flushed (to free up space
for the null key generation).

The null EC primary is now generated using the Storage profile
outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of
this key (the hash of the public area) is computed and compared to the
null seed name presented by the kernel in
/sys/class/tpm/tpm0/null_name.  If the names do not match, the TPM is
compromised.  If the names match, the user performs a TPM2_Certify()
using the null primary as the object handle and the loaded private key
as the sign handle and providing randomized qualifying data.  The
signature of the returned certifyInfo is verified against the public
part of the loaded private key and the qualifying data checked to
prevent replay.  If all of these tests pass, the user is now assured
that TPM integrity and privacy was preserved across the entire boot
sequence of this kernel.

.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 17:34 Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks James Bottomley
@ 2018-11-19 20:05 ` Jason Gunthorpe
  2018-11-19 20:20   ` James Bottomley
  2018-11-20 11:10 ` Jarkko Sakkinen
  2018-12-10 16:33 ` Ken Goldman
  2 siblings, 1 reply; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-19 20:05 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, Nov 19, 2018 at 09:34:04AM -0800, James Bottomley wrote:

> The current state of the art for snooping the TPM Genie hardware
> interposer https://www.nccgroup.trust/us/our-research/tpm-genie/ which
> is a simple external device that can be installed in a couple of
> seconds on any system or laptop.  However, the next phase of research
> seems to be hacking existing devices on the bus to act as interposers,
> so the fact that the attacker requires physical access for a few
> seconds might evaporate.  However, the goal of this document is to
> protect TPM secrets and integrity as far as we are able in this
> environment and to try to insure that if we can't prevent the attack
> then at least we can detect it.
> 
> Unfortunately, most of the TPM functionality, including the hardware
> reset capability can be controlled by an attacker who has access to
> the bus, so we'll discuss some of the disruption possibilities below.
> 
> Measurement (PCR) Integrity
> 
> Since the attacker can send their own commands to the TPM, they can
> send arbitrary PCR extends and thus disrupt the measurement system,
> which would be an annoying denial of service attack.  However, there
> are two, more serious, classes of attack aimed at entities sealed to
> trust measurements.
> 
> 1. The attacker could intercept all PCR extends coming from the system
>    and completely substitute their own values, producing a replay of
>    an untampered state that would cause PCR measurements to attest to
>    a trusted state and release secrets
> 
> 2. At some point in time the attacker could reset the TPM, clearing
>    the PCRs and then send down their own measurements which would
>    effectively overwrite the boot time measurements the TPM has
>    already done.

I can just de-solder the TPM, attach it to a rig and do whatever I
want to it, including fake PCR loads and trigger seal/uneal of any
data I like.

The promise of the TPM was never that PCR protected elements would be
secure against something that has control over the physical hardware
bus.

The treat model for PCR users always contained the implicit assumption
that the security of the physical TPM HW, and the secure linkage to
the CPU (ie secure control over reset, and other things) is
maintained.

So, I'm not sure adding more crypto here really fits with the threat
model the TPM lives in?

That said, certainly there are other non-PCR use cases where this
stuff becomes important. For instance anything using shared secrets
should absolutely establish a crypto unsnoopable path to the TPM.

> Certain information passing in and out of the TPM, such as key sealing
> and private key import and random number generation, is vulnerable to
> interception which HMAC protection alone cannot protect, so for these
> types of command we must also employ request and response encryption
> to prevent the loss of secret information.

Thwarting passive observation seems like a reasonable goal to
me. Attaching a snooper has much less invasion and risk than doing
something active.

But I'm not sure the complexity of a null key is needed here? Won't
any readable key in the TPM do this job?

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 20:05 ` Jason Gunthorpe
@ 2018-11-19 20:20   ` James Bottomley
  2018-11-19 21:19     ` Jason Gunthorpe
  0 siblings, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-11-19 20:20 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, 2018-11-19 at 13:05 -0700, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2018 at 09:34:04AM -0800, James Bottomley wrote:
> 
> > The current state of the art for snooping the TPM Genie hardware
> > interposer https://www.nccgroup.trust/us/our-research/tpm-genie/
> > which
> > is a simple external device that can be installed in a couple of
> > seconds on any system or laptop.  However, the next phase of
> > research
> > seems to be hacking existing devices on the bus to act as
> > interposers,
> > so the fact that the attacker requires physical access for a few
> > seconds might evaporate.  However, the goal of this document is to
> > protect TPM secrets and integrity as far as we are able in this
> > environment and to try to insure that if we can't prevent the
> > attack
> > then at least we can detect it.
> > 
> > Unfortunately, most of the TPM functionality, including the
> > hardware
> > reset capability can be controlled by an attacker who has access to
> > the bus, so we'll discuss some of the disruption possibilities
> > below.
> > 
> > Measurement (PCR) Integrity
> > 
> > Since the attacker can send their own commands to the TPM, they can
> > send arbitrary PCR extends and thus disrupt the measurement system,
> > which would be an annoying denial of service attack.  However,
> > there
> > are two, more serious, classes of attack aimed at entities sealed
> > to
> > trust measurements.
> > 
> > 1. The attacker could intercept all PCR extends coming from the
> > system
> >    and completely substitute their own values, producing a replay
> > of
> >    an untampered state that would cause PCR measurements to attest
> > to
> >    a trusted state and release secrets
> > 
> > 2. At some point in time the attacker could reset the TPM, clearing
> >    the PCRs and then send down their own measurements which would
> >    effectively overwrite the boot time measurements the TPM has
> >    already done.
> 
> I can just de-solder the TPM, attach it to a rig and do whatever I
> want to it, including fake PCR loads and trigger seal/uneal of any
> data I like.

You wouldn't be able to resolder the TPM without causing a reset and
losing the PCR values.

The TPM is not designed to be secure against physical attacks that go
after its internal seed values, that's true.  It is supposed to be
secure against attacks that go after the information transmission into
and out of the TPM, which is what the interposer is doing ... it's just
far lower in the stack than we were expecting.

> The promise of the TPM was never that PCR protected elements would be
> secure against something that has control over the physical hardware
> bus.

I agree as I say ... all we can guarantee is that our extensions go to
the PCRs or we see an error ... we can't guarantee the integrity of the
final measurements because the attacker can still have undetectably
added their own PCR extensions.

> The treat model for PCR users always contained the implicit
> assumption that the security of the physical TPM HW, and the secure
> linkage to the CPU (ie secure control over reset, and other things)
> is maintained.
> 
> So, I'm not sure adding more crypto here really fits with the threat
> model the TPM lives in?

It is, because the attack is a man in the middle, even if it's at the
bus level, which TPM crypto and HMAC is supposed to thwart.  For the
PCR case I just care about forcing our measurements or detecting their
loss ... that's good enough, I think because it means that the attacker
can disrupt the TPM measurements but can't set them to expected values
which is a reasonable thing to guarantee if we do secrets sealing to
PCR values.

> That said, certainly there are other non-PCR use cases where this
> stuff becomes important. For instance anything using shared secrets
> should absolutely establish a crypto unsnoopable path to the TPM.
> 
> > Certain information passing in and out of the TPM, such as key
> > sealing and private key import and random number generation, is
> > vulnerable to interception which HMAC protection alone cannot
> > protect, so for these types of command we must also employ request
> > and response encryption to prevent the loss of secret information.
> 
> Thwarting passive observation seems like a reasonable goal to
> me. Attaching a snooper has much less invasion and risk than doing
> something active.
> 
> But I'm not sure the complexity of a null key is needed here? Won't
> any readable key in the TPM do this job?

In theory, but we don't seem to have one.  The theory is that TPMs come
provisioned according to the TCG guidance which specifies RSA and
EC storage keys be at 81000001 and 81000002 respectively ... it just
seems that the current TPM generation don't respect this, so they come
with no permanent keys at all.

Since we have to derive a primary key anyway, the null seed seems more
useful because of the reset detection.

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 20:20   ` James Bottomley
@ 2018-11-19 21:19     ` Jason Gunthorpe
  2018-11-19 21:34       ` James Bottomley
  0 siblings, 1 reply; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-19 21:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, Nov 19, 2018 at 12:20:39PM -0800, James Bottomley wrote:
> On Mon, 2018-11-19 at 13:05 -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 09:34:04AM -0800, James Bottomley wrote:
> > 
> > > The current state of the art for snooping the TPM Genie hardware
> > > interposer https://www.nccgroup.trust/us/our-research/tpm-genie/
> > > which
> > > is a simple external device that can be installed in a couple of
> > > seconds on any system or laptop.  However, the next phase of
> > > research
> > > seems to be hacking existing devices on the bus to act as
> > > interposers,
> > > so the fact that the attacker requires physical access for a few
> > > seconds might evaporate.  However, the goal of this document is to
> > > protect TPM secrets and integrity as far as we are able in this
> > > environment and to try to insure that if we can't prevent the
> > > attack
> > > then at least we can detect it.
> > > 
> > > Unfortunately, most of the TPM functionality, including the
> > > hardware
> > > reset capability can be controlled by an attacker who has access to
> > > the bus, so we'll discuss some of the disruption possibilities
> > > below.
> > > 
> > > Measurement (PCR) Integrity
> > > 
> > > Since the attacker can send their own commands to the TPM, they can
> > > send arbitrary PCR extends and thus disrupt the measurement system,
> > > which would be an annoying denial of service attack.  However,
> > > there
> > > are two, more serious, classes of attack aimed at entities sealed
> > > to
> > > trust measurements.
> > > 
> > > 1. The attacker could intercept all PCR extends coming from the
> > > system
> > >    and completely substitute their own values, producing a replay
> > > of
> > >    an untampered state that would cause PCR measurements to attest
> > > to
> > >    a trusted state and release secrets
> > > 
> > > 2. At some point in time the attacker could reset the TPM, clearing
> > >    the PCRs and then send down their own measurements which would
> > >    effectively overwrite the boot time measurements the TPM has
> > >    already done.
> > 
> > I can just de-solder the TPM, attach it to a rig and do whatever I
> > want to it, including fake PCR loads and trigger seal/uneal of any
> > data I like.
> 
> You wouldn't be able to resolder the TPM without causing a reset and
> losing the PCR values.

The attacker would issue extend commands and reload the PCR values.

In the PCR thread model the data used in TPM extend commands is not
considered secret.

ie for extends issued by linux, these are all easy to compute, we have
the source code and there is no secret information mixed in. Get a
copy of /boot and you know the values.

For the BIOS, this might need some inside info, or reverse
engineering, but it is still not secret. Ultimately it is various
hashes of static information stored in flash. At worst inserting a
false TPM would capture the information once for a specific hardware..

> The TPM is not designed to be secure against physical attacks that go
> after its internal seed values, that's true.  It is supposed to be
> secure against attacks that go after the information transmission into
> and out of the TPM, which is what the interposer is doing

The TPM is supposed to be secure in the sense it will not disclose its
internal secret information on its pins. De-lidding and other physical
things may disclose the information.

However, the PCR security model is a bit different, and hinges on a
cascading chain of trust. The very top of that chain is the PCB the
TPM is installed in, and from there it goes to the other chips
installed on the PCB, then the code in the BIOS, etc.

Break the PCB and you break the top of the chain of trust. All
security of the PCR is totally lost. Adding more encryption down the
line can't fixup the broken top of chain of trust.

This is why I don't think it makes sense to consider a threat model
for PCRs that contemplates any manipulation of the PCB..

> > The treat model for PCR users always contained the implicit
> > assumption that the security of the physical TPM HW, and the secure
> > linkage to the CPU (ie secure control over reset, and other things)
> > is maintained.
> > 
> > So, I'm not sure adding more crypto here really fits with the threat
> > model the TPM lives in?
> 
> It is, because the attack is a man in the middle, even if it's at the
> bus level, which TPM crypto and HMAC is supposed to thwart.

Sure, for stuff working with shared secrets, etc, this make sense. But
PCR extends are not secret, so there is no reason to encrypt them on
the bus.

And if someone manipulates the unencrypted PCR extend commands then we
are back to 'the PCB is broken' and all PCR based security has been
lost.

> In theory, but we don't seem to have one.  The theory is that TPMs come
> provisioned according to the TCG guidance which specifies RSA and
> EC storage keys be at 81000001 and 81000002 respectively ... it just
> seems that the current TPM generation don't respect this, so they come
> with no permanent keys at all.

Seems surprising.. And the use models you have don't alwaus load a key
that could be used for this?

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 21:19     ` Jason Gunthorpe
@ 2018-11-19 21:34       ` James Bottomley
  2018-11-19 21:44         ` Jason Gunthorpe
  0 siblings, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-11-19 21:34 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
[...]
> Sure, for stuff working with shared secrets, etc, this make sense.
> But PCR extends are not secret, so there is no reason to encrypt them
> on the bus.

OK, there's a miscommunication here.  I believe the current document
states twice that there's no encryption for PCR operations.  We merely
use a salted HMAC session to ensure that they're reliably received by
the TPM and not altered in-flight.

> And if someone manipulates the unencrypted PCR extend commands then
> we are back to 'the PCB is broken' and all PCR based security has
> been lost.
> 
> > In theory, but we don't seem to have one.  The theory is that TPMs
> > come provisioned according to the TCG guidance which specifies RSA
> > and EC storage keys be at 81000001 and 81000002 respectively ... it
> > just seems that the current TPM generation don't respect this, so
> > they come with no permanent keys at all.
> 
> Seems surprising.. And the use models you have don't alwaus load a
> key that could be used for this?

I think it's because Microsoft realised after the first generation of
TPM 2.0s that not having any key at all was a problem, so lots of them
shipped before the spec got updated and manufacturers are somewhat slow
to retool production lines.  My TPM 2.0 doesn't even have an EC
certificate (although Nuvoton now claims this was a manufacturing
mistake) never mind a derived primary key.

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 21:34       ` James Bottomley
@ 2018-11-19 21:44         ` Jason Gunthorpe
  2018-11-19 22:36           ` James Bottomley
  0 siblings, 1 reply; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-19 21:44 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley wrote:
> On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
> [...]
> > Sure, for stuff working with shared secrets, etc, this make sense.
> > But PCR extends are not secret, so there is no reason to encrypt them
> > on the bus.
> 
> OK, there's a miscommunication here.  I believe the current document
> states twice that there's no encryption for PCR operations.  We merely
> use a salted HMAC session to ensure that they're reliably received by
> the TPM and not altered in-flight.

Sure, but again, what is this preventing?

If you accept that PCB trust is essential for PCR security, then I
think trusting the PCB to deliver the PCR extends is perfectly fine.

> > > In theory, but we don't seem to have one.  The theory is that TPMs
> > > come provisioned according to the TCG guidance which specifies RSA
> > > and EC storage keys be at 81000001 and 81000002 respectively ... it
> > > just seems that the current TPM generation don't respect this, so
> > > they come with no permanent keys at all.
> > 
> > Seems surprising.. And the use models you have don't alwaus load a
> > key that could be used for this?
> 
> I think it's because Microsoft realised after the first generation of
> TPM 2.0s that not having any key at all was a problem, so lots of them
> shipped before the spec got updated and manufacturers are somewhat slow
> to retool production lines.  My TPM 2.0 doesn't even have an EC
> certificate (although Nuvoton now claims this was a manufacturing
> mistake) never mind a derived primary key.

Ah, the usual mess in TPM land then :)

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 21:44         ` Jason Gunthorpe
@ 2018-11-19 22:36           ` James Bottomley
  2018-11-19 23:08             ` Jason Gunthorpe
  0 siblings, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-11-19 22:36 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley wrote:
> > On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
> > [...]
> > > Sure, for stuff working with shared secrets, etc, this make
> > > sense. But PCR extends are not secret, so there is no reason to
> > > encrypt them on the bus.
> > 
> > OK, there's a miscommunication here.  I believe the current
> > document states twice that there's no encryption for PCR
> > operations.  We merely use a salted HMAC session to ensure that
> > they're reliably received by the TPM and not altered in-flight.
> 
> Sure, but again, what is this preventing?

It prevents the interposer having free reign to set the PCR values by
substituting every measurement you send to the TPM.  It also allows you
some scope for detecting the presence of an interposer if it does try
to tamper with your measurements.  I agree there's no guarantee of non
tamper, like there is for confidentiality of sealed data and random
numbers, but it seems to be an improvement on what's currently there
given that we have to install the session machinery for
encryption/decryption anyway.

> If you accept that PCB trust is essential for PCR security, then I
> think trusting the PCB to deliver the PCR extends is perfectly fine.

The *current* interposer is a hardware device on the bus.  The next gen
is reported to be more software based.

> > > > In theory, but we don't seem to have one.  The theory is that
> > > > TPMs come provisioned according to the TCG guidance which
> > > > specifies RSA and EC storage keys be at 81000001 and 81000002
> > > > respectively
> > > > ... it
> > > > just seems that the current TPM generation don't respect this,
> > > > so
> > > > they come with no permanent keys at all.
> > > 
> > > Seems surprising.. And the use models you have don't alwaus load
> > > a key that could be used for this?
> > 
> > I think it's because Microsoft realised after the first generation
> > of TPM 2.0s that not having any key at all was a problem, so lots
> > of them shipped before the spec got updated and manufacturers are
> > somewhat slow to retool production lines.  My TPM 2.0 doesn't even
> > have an EC certificate (although Nuvoton now claims this was a
> > manufacturing mistake) never mind a derived primary key.
> 
> Ah, the usual mess in TPM land then :)

Yes, sigh.

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 22:36           ` James Bottomley
@ 2018-11-19 23:08             ` Jason Gunthorpe
  2018-11-20  0:54               ` James Bottomley
  0 siblings, 1 reply; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-19 23:08 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, Nov 19, 2018 at 02:36:28PM -0800, James Bottomley wrote:
> On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley wrote:
> > > On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
> > > [...]
> > > > Sure, for stuff working with shared secrets, etc, this make
> > > > sense. But PCR extends are not secret, so there is no reason to
> > > > encrypt them on the bus.
> > > 
> > > OK, there's a miscommunication here.  I believe the current
> > > document states twice that there's no encryption for PCR
> > > operations.  We merely use a salted HMAC session to ensure that
> > > they're reliably received by the TPM and not altered in-flight.
> > 
> > Sure, but again, what is this preventing?
> 
> It prevents the interposer having free reign to set the PCR values by
> substituting every measurement you send to the TPM.  

But the threat model for PCR excludes the possibility of an
interposer. If you have an interposer the PCB is broken and all PCR
security is already lost.

> some scope for detecting the presence of an interposer if it does try
> to tamper with your measurements.

But I can still tamper with them.. I can have the interposer
delete/fail the kernel PCR commands and issue un-hashed ones.

The kernel would have to do something extreme like fault the TPM and
totally disable the linux device if any PCR extend fails. That should
probably be included in the plan?

> tamper, like there is for confidentiality of sealed data and random
> numbers, but it seems to be an improvement on what's currently there
> given that we have to install the session machinery for
> encryption/decryption anyway.

Sure, if you have the machinery and it can be used at PCR time, then
why not use it.. But I think any description about why this is being
done should be clear about what the threat model is for PCR. 

I'm mostly concerned about how the document was written which makes it
seems like security of extend beyond what is integral to the
PCB/chipset is meaningful, considering the threat model PCR is based
on.

We don't want people to become confused and think they are getting
more security than there really is.

> > If you accept that PCB trust is essential for PCR security, then I
> > think trusting the PCB to deliver the PCR extends is perfectly fine.
> 
> The *current* interposer is a hardware device on the bus.  The next gen
> is reported to be more software based.

Well, that is terrifying.

But a SW based attack that can toggle TPM reset or alter TPM commands
in flight getting very much into the 'chips are broken' territory
where the chain of trust required for PCR is broken. This is breaking
fundamental assumptions of the threat model here :(

It is hard to know if more crypto could really prevent problems
without knowing the details of how this is being done??

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 23:08             ` Jason Gunthorpe
@ 2018-11-20  0:54               ` James Bottomley
  2018-11-20  3:05                 ` Jason Gunthorpe
  0 siblings, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-11-20  0:54 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, 2018-11-19 at 16:08 -0700, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2018 at 02:36:28PM -0800, James Bottomley wrote:
> > On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote:
> > > On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley wrote:
> > > > On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
> > > > [...]
> > > > > Sure, for stuff working with shared secrets, etc, this make
> > > > > sense. But PCR extends are not secret, so there is no reason
> > > > > to
> > > > > encrypt them on the bus.
> > > > 
> > > > OK, there's a miscommunication here.  I believe the current
> > > > document states twice that there's no encryption for PCR
> > > > operations.  We merely use a salted HMAC session to ensure that
> > > > they're reliably received by the TPM and not altered in-flight.
> > > 
> > > Sure, but again, what is this preventing?
> > 
> > It prevents the interposer having free reign to set the PCR values
> > by substituting every measurement you send to the TPM.  
> 
> But the threat model for PCR excludes the possibility of an
> interposer. If you have an interposer the PCB is broken and all PCR
> security is already lost.

Yours might, mine doesn't and I think I can mitigate the we can give
you approved PCRs attack ... I can't prevent the we muck with your PCRs
attack.

> > some scope for detecting the presence of an interposer if it does
> > try to tamper with your measurements.
> 
> But I can still tamper with them.. I can have the interposer
> delete/fail the kernel PCR commands and issue un-hashed ones.

You can't because you don't have the HMAC key to fake the response, so
as long as I check the HMAC return I know you've tampered.

> The kernel would have to do something extreme like fault the TPM and
> totally disable the linux device if any PCR extend fails. That should
> probably be included in the plan?

If we detect an interposer (if one of the HMACs or encrypt/decrypt
fails) it depends on policy what you do.  We certainly log a message saying TPM integrity is compromised.  I think we should also disable the TPM, but I haven't done that yet because I thought it would bear more discussion.

> > tamper, like there is for confidentiality of sealed data and random
> > numbers, but it seems to be an improvement on what's currently
> > there given that we have to install the session machinery for
> > encryption/decryption anyway.
> 
> Sure, if you have the machinery and it can be used at PCR time, then
> why not use it.. But I think any description about why this is being
> done should be clear about what the threat model is for PCR. 

Right, the threat model for me is complete control of the PCRs.  I can
mitigate that by HMACing the request and response and checking the
response HMAC.

> I'm mostly concerned about how the document was written which makes
> it seems like security of extend beyond what is integral to the
> PCB/chipset is meaningful, considering the threat model PCR is based
> on.
> 
> We don't want people to become confused and think they are getting
> more security than there really is.

Agreed.

> > > If you accept that PCB trust is essential for PCR security, then
> > > I think trusting the PCB to deliver the PCR extends is perfectly
> > > fine.
> > 
> > The *current* interposer is a hardware device on the bus.  The next
> > gen is reported to be more software based.
> 
> Well, that is terrifying.
> 
> But a SW based attack that can toggle TPM reset or alter TPM commands
> in flight getting very much into the 'chips are broken' territory
> where the chain of trust required for PCR is broken. This is breaking
> fundamental assumptions of the threat model here :(
> 
> It is hard to know if more crypto could really prevent problems
> without knowing the details of how this is being done??

I think if I can mitigate some of the PCR problems and prevent snooping
for the hardware interposer, it will also go a long way to defeating
the more software one ... of course, not having seen it, this is just a
guess, but it's based on the idea that the software one probably has
the same or more limited access to the bus.

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20  0:54               ` James Bottomley
@ 2018-11-20  3:05                 ` Jason Gunthorpe
  2018-11-20 17:17                   ` James Bottomley
  0 siblings, 1 reply; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-20  3:05 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, Nov 19, 2018 at 04:54:32PM -0800, James Bottomley wrote:
> On Mon, 2018-11-19 at 16:08 -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 02:36:28PM -0800, James Bottomley wrote:
> > > On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote:
> > > > On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley wrote:
> > > > > On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
> > > > > [...]
> > > > > > Sure, for stuff working with shared secrets, etc, this make
> > > > > > sense. But PCR extends are not secret, so there is no reason
> > > > > > to
> > > > > > encrypt them on the bus.
> > > > > 
> > > > > OK, there's a miscommunication here.  I believe the current
> > > > > document states twice that there's no encryption for PCR
> > > > > operations.  We merely use a salted HMAC session to ensure that
> > > > > they're reliably received by the TPM and not altered in-flight.
> > > > 
> > > > Sure, but again, what is this preventing?
> > > 
> > > It prevents the interposer having free reign to set the PCR values
> > > by substituting every measurement you send to the TPM.  
> > 
> > But the threat model for PCR excludes the possibility of an
> > interposer. If you have an interposer the PCB is broken and all PCR
> > security is already lost.
> 
> Yours might, mine doesn't and I think I can mitigate the we can give
> you approved PCRs attack ... I can't prevent the we muck with your PCRs
> attack.

It is not 'mine' or 'your' threat model. These trade offs are baked
into the TPM protocol design itself.

I guess I haven't really heard you explain what your threat model
is.

I would think if an interposer can muck with the PCRs then the main
attack would be to cause the CPU to run code that does not match the
PCRs while tricking the TPM into thinking the PCR matches.

This would let an attack unseal, say, a disk encryption secret while
running a hostile version of Linux. A big failure of the fundamental
PCR guarentee.

So any point along the PCR trust chain that does not do secure PCR
updates is a failure point. Since the BIOS doesn't do it, one would
probably start by replacing the bootloader and kernel in conjunction
with the interposer?

The incremental gain from having the kernel do this seems negligible
to me.

I think to properly address this threat work needs to be done in the
TPM spec to establish a secure TPM communication channel at power on..

> > > some scope for detecting the presence of an interposer if it does
> > > try to tamper with your measurements.
> > 
> > But I can still tamper with them.. I can have the interposer
> > delete/fail the kernel PCR commands and issue un-hashed ones.
> 
> You can't because you don't have the HMAC key to fake the response, so
> as long as I check the HMAC return I know you've tampered.

.. and you stop using the TPM after this. Otherwise the interposer can
fail the command, issue an extend with the right data, and cause the
PCRs to match trusted data while running actually untrusted code.

> > The kernel would have to do something extreme like fault the TPM and
> > totally disable the linux device if any PCR extend fails. That should
> > probably be included in the plan?
> 
> If we detect an interposer (if one of the HMACs or encrypt/decrypt
> fails) it depends on policy what you do.  We certainly log a message
> saying TPM integrity is compromised.  I think we should also disable
> the TPM, but I haven't done that yet because I thought it would bear
> more discussion.

Logging doesn't seem useful - if a HW interposer is present then
someone is already in control of the HW and will happily ignore
warnings ...

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 17:34 Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks James Bottomley
  2018-11-19 20:05 ` Jason Gunthorpe
@ 2018-11-20 11:10 ` Jarkko Sakkinen
  2018-11-20 12:41   ` Jarkko Sakkinen
  2018-11-20 17:23   ` James Bottomley
  2018-12-10 16:33 ` Ken Goldman
  2 siblings, 2 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-20 11:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett



On Mon, Nov 19, 2018 at 09:34:04AM -0800, James Bottomley wrote:
> Hi All,
> 
> I took the action at the Edinburgh meeting to document this, so the
> attached is what I'm proposing (I'll also add this to my patch set
> doing the implementation to live in Documentation/security/tpm/tpm-
> security.rst).  Please could you give it a read; one thing that came
> out of the Edinburgh meeting was that people with too much exposure to
> TPM crypto acquire twists in their brains which mean stuff which seems
> obvious to them isn't to anyone else, so I need external reviewers to
> assure me that the document is understandable by non-TPM security
> people.
> 
> Once this passes the understandability bar, I'll pass it on to
> Microsoft and TianoCore/UEFI as our preferred mechanism for thwarting
> interposer attacks.
> 
> Thanks,
> 
> James
> 
> ---
> 
> TPM Security
> ============
> 
> The object of this document is to describe how we make the kernel's
> use of the TPM reasonably robust in the face of external snooping and
> packet alteration attacks.  The current security document is for TPM
> 2.0.
> 
> Introduction
> ------------
> 
> The TPM is usually a discrete chip attached to a PC via some type of
> low bandwidth bus.  There are exceptions to this such as the Intel
> PTT, which is a software TPM running inside a software environment
> close to the CPU, which are subject to different attacks, but right at
> the moment, most hardened security environments require a discrete
> hardware TPM, which is the use case discussed here.
> 
> Snooping and Alteration Attacks against the bus
> -----------------------------------------------
> 
> The current state of the art for snooping the TPM Genie hardware
> interposer https://www.nccgroup.trust/us/our-research/tpm-genie/ which
> is a simple external device that can be installed in a couple of
> seconds on any system or laptop.  However, the next phase of research
> seems to be hacking existing devices on the bus to act as interposers,
> so the fact that the attacker requires physical access for a few
> seconds might evaporate.  However, the goal of this document is to
> protect TPM secrets and integrity as far as we are able in this
> environment and to try to insure that if we can't prevent the attack
> then at least we can detect it.
> 
> Unfortunately, most of the TPM functionality, including the hardware
> reset capability can be controlled by an attacker who has access to
> the bus, so we'll discuss some of the disruption possibilities below.
> 
> Measurement (PCR) Integrity
> ---------------------------
> 
> Since the attacker can send their own commands to the TPM, they can
> send arbitrary PCR extends and thus disrupt the measurement system,
> which would be an annoying denial of service attack.  However, there
> are two, more serious, classes of attack aimed at entities sealed to
> trust measurements.
> 
> 1. The attacker could intercept all PCR extends coming from the system
>    and completely substitute their own values, producing a replay of
>    an untampered state that would cause PCR measurements to attest to
>    a trusted state and release secrets
> 
> 2. At some point in time the attacker could reset the TPM, clearing
>    the PCRs and then send down their own measurements which would
>    effectively overwrite the boot time measurements the TPM has
>    already done.
> 
> The first can be thwarted by always doing HMAC protection of the PCR
> extend and read command meaning measurement values cannot be
> substituted without producing a detectable HMAC failure in the
> response.  However, the second can only really be detected by relying
> on some sort of mechanism for protection which would change over TPM
> reset.
> 
> Secrets Guarding
> ----------------
> 
> Certain information passing in and out of the TPM, such as key sealing
> and private key import and random number generation, is vulnerable to
> interception which HMAC protection alone cannot protect, so for these
> types of command we must also employ request and response encryption
> to prevent the loss of secret information.
> 
> Establishing Initial Trust with the TPM
> ---------------------------------------
> 
> In order to provide security from the beginning, an initial shared or
> asymmetric secret must be established which must also be unknown to
> the attacker.  The most obvious avenues for this are the endorsement
> and storage seeds, which can be used to derive asymmetric keys.
> However, using these keys is difficult because the only way to pass
> them into the kernel would be on the command line, which requires
> extensive support in the boot system, and there's no guarantee that
> either hierarchy would not have some type of authorization.
> 
> The mechanism chosen for the Linux Kernel is to derive the primary
> elliptic curve key from the null seed using the standard storage seed
> parameters.  The null seed has two advantages: firstly the hierarchy
> physically cannot have an authorization, so we are always able to use
> it and secondly, the null seed changes across TPM resets, meaning if
> we establish trust on the null seed at start of day, all sessions
> salted with the derived key will fail if the TPM is reset and the seed
> changes.
> 
> Obviously using the null seed without any other prior shared secrets,
> we have to create and read the initial public key which could, of
> course, be intercepted and substituted by the bus interposer.
> However, the TPM has a key certification mechanism (using the EK
> endorsement certificate, creating an attestation identity key and
> certifying the null seed primary with that key) which is too complex
> to run within the kernel, so we keep a copy of the null primary key
> name, which is what is certified so user-space can run the full
> certification when it boots.  The definitive guarantee here is that if
> the null primary key certifies correctly, you know all your TPM
> transactions since start of day were secure and if it doesn't, you
> know there's an interposer on your system (and that any secret used
> during boot may have been leaked).
> 
> Stacking Trust
> --------------
> 
> In the current null primary scenario, the TPM must be completely
> cleared before handing it on to the next consumer.  However the kernel
> hands to user-space the name of the derived null seed key which can
> then be verified by certification in user-space.  Therefore, this chain
> of name handoff can be used between the various boot components as
> well (via an unspecified mechanism).  For instance, grub could use the
> null seed scheme for security and hand the name off to the kernel in
> the boot area.  The kernel could make its own derivation of the key
> and the name and know definitively that if they differ from the handed
> off version that tampering has occurred.  Thus it becomes possible to
> chain arbitrary boot components together (UEFI to grub to kernel) via
> the name handoff provided each successive component knows how to
> collect the name and verifies it against its derived key.
> 
> Session Properties
> ------------------
> 
> All TPM commands the kernel uses allow sessions.  HMAC sessions may be
> used to check the integrity of requests and responses and decrypt and
> encrypt flags may be used to shield parameters and responses.  The
> HMAC and encryption keys are usually derived from the shared
> authorization secret, but for a lot of kernel operations that is well
> known (and usually empty).  Thus, every HMAC session used by the
> kernel must be created using the null primary key as the salt key
> which thus provides a cryptographic input into the session key
> derivation.  Thus, the kernel creates the null primary key once (as a
> volatile TPM handle) and keeps it around in the kernel TPM space for
> every in-kernel use of the TPM.  Currently, because of a lack of
> de-gapping in the in-kernel resource manager, the session must be
> created and destroyed for each operation, but, in future, a single
> session may also be reused for the in-kernel HMAC, encryption and
> decryption sessions.
> 
> Protection Types
> ----------------
> 
> For every in-kernel operation we use null primary salted HMAC to
> protect the integrity.  Additionally, we use parameter encryption to
> protect key sealing and parameter decryption to protect key unsealing
> and random number generation.
> 
> Null Primary Key Certification in Userspace
> ===========================================
> 
> Every TPM comes shipped with a couple of X.509 certificates for the
> primary endorsement key.  This document assumes that the Elliptic
> Curve version of the certificate exists at 01C00002, but will work
> equally well with the RSA certificate (at 01C00001).
> 
> The first step in the certification is primary creation using the
> template from the `TCG EK Credential Profile`_ which allows comparison
> of the generated primary key against the one in the certificate (the
> public key must match).  Note that generation of the EK primary
> requires the EK hierarchy password, but a pre-generated version of the
> EC primary should exist at 81010002 and a TPM2_ReadPublic() may be
> performed on this without needing the key authority.  Next, the
> certificate itself must be verified to chain back to the manufacturer
> root (which should be published on the manufacturer website).  Once
> this is done, the generated EK primary key may now be used to run an
> attestation on the null seed.  The specific problem here is that the
> EK primary is not a signing key so cannot on its own be used to sign
> the key certification, hence the complex process below.
> 
> Note: this process is a simplified abbreviation of the usual privacy
> CA based attestation process.  The assumption here is that the
> attestation is done by the TPM owner who thus has access to only the
> owner hierarchy.  The owner creates an external public/private key
> pair (assume elliptic curve in this case) and wraps the private key
> for import using an inner wrapping process and parented to the EC
> derived storage primary.  The TPM2_Import() is done using a parameter
> decryption HMAC session salted to the EK primary (which also does not
> require the EK key authority) meaning that the inner wrapping key is
> the encrypted parameter and thus the TPM will not be able to perform
> the import unless is possesses the certified EK so if the command
> succeeds and the HMAC verifies on return we know we have a loadable
> copy of the private key only for the certified TPM.  This key is now
> loaded into the TPM and the Storage primary flushed (to free up space
> for the null key generation).
> 
> The null EC primary is now generated using the Storage profile
> outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of
> this key (the hash of the public area) is computed and compared to the
> null seed name presented by the kernel in
> /sys/class/tpm/tpm0/null_name.  If the names do not match, the TPM is
> compromised.  If the names match, the user performs a TPM2_Certify()
> using the null primary as the object handle and the loaded private key
> as the sign handle and providing randomized qualifying data.  The
> signature of the returned certifyInfo is verified against the public
> part of the loaded private key and the qualifying data checked to
> prevent replay.  If all of these tests pass, the user is now assured
> that TPM integrity and privacy was preserved across the entire boot
> sequence of this kernel.
> 
> .. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
> .. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/

This is basically rewrite of TPM genie paper with extras. Maybe just
shorten it to include the proposed architecture and point to the TPM
Genie paper (which is not in the references at all ATM).

The way I see it the data validation is way more important than
protecting against physical interposer to be frank.

The attack scenario would require to open the damn device. For laptop
that would leave physical marks (i.e. evil maid). In a data center with
armed guards I would wish you good luck accomplishing it. It is not
anything like sticking a USB stick and run.

We can take a fix into Linux with a clean implementation but it needs
to be an opt-in feature because not all users will want to use it.

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 11:10 ` Jarkko Sakkinen
@ 2018-11-20 12:41   ` Jarkko Sakkinen
  2018-11-20 17:25     ` James Bottomley
  2018-11-20 17:23   ` James Bottomley
  1 sibling, 1 reply; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-20 12:41 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
> This is basically rewrite of TPM genie paper with extras. Maybe just
> shorten it to include the proposed architecture and point to the TPM
> Genie paper (which is not in the references at all ATM).
> 
> The way I see it the data validation is way more important than
> protecting against physical interposer to be frank.
> 
> The attack scenario would require to open the damn device. For laptop
> that would leave physical marks (i.e. evil maid). In a data center with
> armed guards I would wish you good luck accomplishing it. It is not
> anything like sticking a USB stick and run.
> 
> We can take a fix into Linux with a clean implementation but it needs
> to be an opt-in feature because not all users will want to use it.

Someone (might have been either Mimi or David Howells but cannot recall)
correctly pointed out at LSS 2018 that you could just as easily spy and
corrupt RAM if you have a time window to perform this type of attack.

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20  3:05                 ` Jason Gunthorpe
@ 2018-11-20 17:17                   ` James Bottomley
  2018-11-20 21:33                     ` Jason Gunthorpe
  2018-11-20 23:41                     ` Jarkko Sakkinen
  0 siblings, 2 replies; 34+ messages in thread
From: James Bottomley @ 2018-11-20 17:17 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Mon, 2018-11-19 at 20:05 -0700, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2018 at 04:54:32PM -0800, James Bottomley wrote:
> > On Mon, 2018-11-19 at 16:08 -0700, Jason Gunthorpe wrote:
> > > On Mon, Nov 19, 2018 at 02:36:28PM -0800, James Bottomley wrote:
> > > > On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote:
> > > > > On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley
> > > > > wrote:
> > > > > > On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
> > > > > > [...]
> > > > > > > Sure, for stuff working with shared secrets, etc, this
> > > > > > > make sense. But PCR extends are not secret, so there is
> > > > > > > no reason to encrypt them on the bus.
> > > > > > 
> > > > > > OK, there's a miscommunication here.  I believe the current
> > > > > > document states twice that there's no encryption for PCR
> > > > > > operations.  We merely use a salted HMAC session to ensure
> > > > > > that they're reliably received by the TPM and not altered
> > > > > > in-flight.
> > > > > 
> > > > > Sure, but again, what is this preventing?
> > > > 
> > > > It prevents the interposer having free reign to set the PCR
> > > > values by substituting every measurement you send to the TPM.  
> > > 
> > > But the threat model for PCR excludes the possibility of an
> > > interposer. If you have an interposer the PCB is broken and all
> > > PCR security is already lost.
> > 
> > Yours might, mine doesn't and I think I can mitigate the we can
> > give you approved PCRs attack ... I can't prevent the we muck with
> > your PCRs attack.
> 
> It is not 'mine' or 'your' threat model. These trade offs are baked
> into the TPM protocol design itself.
> 
> I guess I haven't really heard you explain what your threat model
> is.

OK, the TPM is supposed to provide attestation of the correct
environment on a device under someone else's control (the classic
example is laptop provided by a company to an employee).  The device is
under the physical control of the entity you don't entirely trust so
the TPM is supposed to attest that they're running an approved OS ...
we have whole TCG specs for that situation.

You seem to be saying it's not viable to expect the TPM to function in
the above environment and I'm saying I think it is but we may have to
adjust our definition of "function".

This is the situation where I want to get confirmation that PCR
measurements went to the TPM and detach it if they don't.

request/response encryption is probably most useful in the case of self
owned devices that may have suffered third party interference with a
view to stealing secrets (think foreign government finds your powered
off laptop in your hotel room), the so called "evil maid" attack.

Personally, since I own my own laptop, I care about the latter, but I
think, since we have infrastructures relying on it that we, as
responsible kernel developers, have to care about the former as well.

> I would think if an interposer can muck with the PCRs then the main
> attack would be to cause the CPU to run code that does not match the
> PCRs while tricking the TPM into thinking the PCR matches.

The interposer sits on the serial bus ... it has no contact with the
CPU.  That's the point about it, it's a simple to attach easy to
construct device because the TPM bus (LPC, i2c, spi etc) is easy to
interface to.  getting a device which can man in the middle the main
CPU address bus, say, is at least an order of magnitude more difficult.

The point about interposers is that they address the technology gap. 
Sure it was possible to use a Focussed Ion Beam to extract secrets from
a decapped TPM like the black hat guys did but that's just impractical
for the average user as is the JTAG technology that would allow you to
interface with the main CPU bus.  An interposer is a very practical and
easy to install device.

James


> This would let an attack unseal, say, a disk encryption secret while
> running a hostile version of Linux. A big failure of the fundamental
> PCR guarentee.
> 
> So any point along the PCR trust chain that does not do secure PCR
> updates is a failure point. Since the BIOS doesn't do it, one would
> probably start by replacing the bootloader and kernel in conjunction
> with the interposer?
> 
> The incremental gain from having the kernel do this seems negligible
> to me.
> 
> I think to properly address this threat work needs to be done in the
> TPM spec to establish a secure TPM communication channel at power
> on..
> 
> > > > some scope for detecting the presence of an interposer if it
> > > > does
> > > > try to tamper with your measurements.
> > > 
> > > But I can still tamper with them.. I can have the interposer
> > > delete/fail the kernel PCR commands and issue un-hashed ones.
> > 
> > You can't because you don't have the HMAC key to fake the response,
> > so
> > as long as I check the HMAC return I know you've tampered.
> 
> .. and you stop using the TPM after this. Otherwise the interposer
> can
> fail the command, issue an extend with the right data, and cause the
> PCRs to match trusted data while running actually untrusted code.
> 
> > > The kernel would have to do something extreme like fault the TPM
> > > and
> > > totally disable the linux device if any PCR extend fails. That
> > > should
> > > probably be included in the plan?
> > 
> > If we detect an interposer (if one of the HMACs or encrypt/decrypt
> > fails) it depends on policy what you do.  We certainly log a
> > message
> > saying TPM integrity is compromised.  I think we should also
> > disable
> > the TPM, but I haven't done that yet because I thought it would
> > bear
> > more discussion.
> 
> Logging doesn't seem useful - if a HW interposer is present then
> someone is already in control of the HW and will happily ignore
> warnings ...
> 
> Jason
> 


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 11:10 ` Jarkko Sakkinen
  2018-11-20 12:41   ` Jarkko Sakkinen
@ 2018-11-20 17:23   ` James Bottomley
  2018-11-20 23:12     ` Jarkko Sakkinen
  1 sibling, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-11-20 17:23 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett

On Tue, 2018-11-20 at 13:10 +0200, Jarkko Sakkinen wrote:
[...]
> This is basically rewrite of TPM genie paper with extras. just
> shorten it to include the proposed architecture and point to the TPM
> Genie paper (which is not in the references at all ATM).

I really don't think so.  The paper only gives details of bound
authorization sessions for TPM 2.0 which suffer from no to weak entropy
problems.  The reason for using salted ones in the document, which
aren't mentioned at all in the genie paper, is so we have a high
entropy cryptographically unguessable HMAC and encryption key.

> The way I see it the data validation is way more important than
> protecting against physical interposer to be frank.
> 
> The attack scenario would require to open the damn device.

Yes (well, currently).

>  For laptop that would leave physical marks (i.e. evil maid).

Only if you have some type of security seal, which most laptops don't
have.

James

>  In a data center with armed guards I would wish you good luck
> accomplishing it. It is not anything like sticking a USB stick and
> run.
> 
> We can take a fix into Linux with a clean implementation but it needs
> to be an opt-in feature because not all users will want to use it.
> 
> /Jarkko
> 


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 12:41   ` Jarkko Sakkinen
@ 2018-11-20 17:25     ` James Bottomley
  2018-11-20 23:13       ` Jarkko Sakkinen
  0 siblings, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-11-20 17:25 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett

On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
> > This is basically rewrite of TPM genie paper with extras. Maybe
> > just shorten it to include the proposed architecture and point to
> > the TPM Genie paper (which is not in the references at all ATM).
> > 
> > The way I see it the data validation is way more important than
> > protecting against physical interposer to be frank.
> > 
> > The attack scenario would require to open the damn device. For
> > laptop that would leave physical marks (i.e. evil maid). In a data
> > center with armed guards I would wish you good luck accomplishing
> > it. It is not anything like sticking a USB stick and run.
> > 
> > We can take a fix into Linux with a clean implementation but it
> > needs to be an opt-in feature because not all users will want to
> > use it.
> 
> Someone (might have been either Mimi or David Howells but cannot
> recall) correctly pointed out at LSS 2018 that you could just as
> easily spy and corrupt RAM if you have a time window to perform this
> type of attack.

Not using the simple plug in on the TPM bus, you can't.  The point is
basically the difference in the technology: the interposer is a simple,
easy to construct, plugin; a RAM spy is a huge JTAG thing that would be
hard even to fit into a modern thin laptop, let alone extremely
difficult to build.

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 17:17                   ` James Bottomley
@ 2018-11-20 21:33                     ` Jason Gunthorpe
  2018-11-20 22:34                       ` James Bottomley
  2018-11-20 23:52                       ` Jarkko Sakkinen
  2018-11-20 23:41                     ` Jarkko Sakkinen
  1 sibling, 2 replies; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-20 21:33 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 09:17:59AM -0800, James Bottomley wrote:

> > > Yours might, mine doesn't and I think I can mitigate the we can
> > > give you approved PCRs attack ... I can't prevent the we muck with
> > > your PCRs attack.
> > 
> > It is not 'mine' or 'your' threat model. These trade offs are baked
> > into the TPM protocol design itself.
> > 
> > I guess I haven't really heard you explain what your threat model
> > is.
> 
> OK, the TPM is supposed to provide attestation of the correct
> environment on a device under someone else's control (the classic
> example is laptop provided by a company to an employee).  The device is
> under the physical control of the entity you don't entirely trust so
> the TPM is supposed to attest that they're running an approved OS ...
> we have whole TCG specs for that situation.

Well.. Attestation started out as a way to prove things about hardware
you physically control - ie data center servers. That they haven't
been manipulated.

I'm not surprised people want to use this on the client, but in this
case you really have to trust the employee to not disassemble the
laptop...

The idea that it could extend to HW you don't control is, frankly, a
bit of wishful thinking. The system is strong enough to defend against
casual abuse, but a determined and funded adversary has, many, many,
options to create a situation where the TPM attests the system is
running software that it actually isn't.

The scary thing about the interposer is how inexpensive and simple it
is, many other attacks require considerable determination and funding.

> > I would think if an interposer can muck with the PCRs then the main
> > attack would be to cause the CPU to run code that does not match the
> > PCRs while tricking the TPM into thinking the PCR matches.
> 
> The interposer sits on the serial bus ... it has no contact with the
> CPU.  That's the point about it, it's a simple to attach easy to
> construct device because the TPM bus (LPC, i2c, spi etc) is easy to
> interface to.  getting a device which can man in the middle the main
> CPU address bus, say, is at least an order of magnitude more difficult.

It doesn't need contact with the CPU. The basic flow would be to use
the interposer on SPI or LPC to block the Nth PCR update, having
determined that Nth comes from the BIOS and covers the
bootloader.. The BIOS ignores the error, or can't tell the PCR update
was corrupted. From there it is easy to see how to get into a hostile
kernel and extend the PCRs to match a trusted kernel.

But even this convoluted attack is kind of silly. If I can touch the
TPM physically then just boot into my hostile kernel and *trigger TPM
reset*. Then I can simply issue reset and then extends from the
hostile kernel to mimic a trusted system. Easy! One wire and a
microscope will do the job!

So it really is essential that all steps, including the BIOS use
secure PCR updates, or you may as well not bother in Linux, at least
for security reasons.

And I think you were on the right track, the TPM should have a
per-boot authorization that flows through all layers of the TPM stack
and guarantees the TPM hasn't been rebooted and with crypto prevents
lost PCR updates. 

But that does require standardization, as we do need the BIOS to
participate.

Though keep in mind, tt doesn't prevent physical access from
manipulating the PCRs, it just makes it more expensive than one wire
and a microscope. Maybe it now involves de-soldering, etc.

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 21:33                     ` Jason Gunthorpe
@ 2018-11-20 22:34                       ` James Bottomley
  2018-11-20 23:39                         ` Jason Gunthorpe
  2018-11-20 23:52                       ` Jarkko Sakkinen
  1 sibling, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-11-20 22:34 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Tue, 2018-11-20 at 14:33 -0700, Jason Gunthorpe wrote:
> On Tue, Nov 20, 2018 at 09:17:59AM -0800, James Bottomley wrote:
> 
> > > > Yours might, mine doesn't and I think I can mitigate the we can
> > > > give you approved PCRs attack ... I can't prevent the we muck
> > > > with your PCRs attack.
> > > 
> > > It is not 'mine' or 'your' threat model. These trade offs are
> > > baked into the TPM protocol design itself.
> > > 
> > > I guess I haven't really heard you explain what your threat model
> > > is.
> > 
> > OK, the TPM is supposed to provide attestation of the correct
> > environment on a device under someone else's control (the classic
> > example is laptop provided by a company to an employee).  The
> > device is under the physical control of the entity you don't
> > entirely trust so the TPM is supposed to attest that they're
> > running an approved OS ... we have whole TCG specs for that
> > situation.
> 
> Well.. Attestation started out as a way to prove things about
> hardware you physically control - ie data center servers. That they
> haven't been manipulated.
> 
> I'm not surprised people want to use this on the client, but in this
> case you really have to trust the employee to not disassemble the
> laptop...
> 
> The idea that it could extend to HW you don't control is, frankly, a
> bit of wishful thinking. The system is strong enough to defend
> against casual abuse, but a determined and funded adversary has,
> many, many, options to create a situation where the TPM attests the
> system is running software that it actually isn't.

I don't disagree, but this is their site not mine:

https://trustedcomputinggroup.org/resource/implementing-hardware-roots-of-trust/

and the industry expects us at least to make an effort to support them
in using it.  I fully agree it's nowhere near foolproof.  However, I
think the plan proposed is a reasonable course of action against
interposers ... it's certainly better than doing nothing.

> The scary thing about the interposer is how inexpensive and simple it
> is, many other attacks require considerable determination and
> funding.

Yes, that's my exact point: a nation state can definitely overcome a
TPM in a system they possess.  Previously it wasn't thought possible
with $10 of hardware, a screwdriver and about 5 minutes of access,
which has tipped the tables somewhat.

> > > I would think if an interposer can muck with the PCRs then the
> > > main attack would be to cause the CPU to run code that does not
> > > match the PCRs while tricking the TPM into thinking the PCR
> > > matches.
> > 
> > The interposer sits on the serial bus ... it has no contact with
> > the CPU.  That's the point about it, it's a simple to attach easy
> > to construct device because the TPM bus (LPC, i2c, spi etc) is easy
> > to interface to.  getting a device which can man in the middle the
> > main CPU address bus, say, is at least an order of magnitude more
> > difficult.
> 
> It doesn't need contact with the CPU. The basic flow would be to use
> the interposer on SPI or LPC to block the Nth PCR update, having
> determined that Nth comes from the BIOS and covers the
> bootloader.. The BIOS ignores the error, or can't tell the PCR update
> was corrupted. From there it is easy to see how to get into a hostile
> kernel and extend the PCRs to match a trusted kernel.

Right, but that's why I want to detect the error and shut down the TPM.

> But even this convoluted attack is kind of silly. If I can touch the
> TPM physically then just boot into my hostile kernel and *trigger TPM
> reset*. Then I can simply issue reset and then extends from the
> hostile kernel to mimic a trusted system. Easy! One wire and a
> microscope will do the job!
> 
> So it really is essential that all steps, including the BIOS use
> secure PCR updates, or you may as well not bother in Linux, at least
> for security reasons.

Absolutely agreed on this point: the next step, in fact, is to
circulate the document to Microsoft and the UEFI people to see if they
want to use it as part of their defence against this.  Ideally if we
all agree on the null seed proposal, we can add passing the name
through the boot interfaces for standardisation.

> And I think you were on the right track, the TPM should have a
> per-boot authorization that flows through all layers of the TPM stack
> and guarantees the TPM hasn't been rebooted and with crypto prevents
> lost PCR updates. 
> 
> But that does require standardization, as we do need the BIOS to
> participate.

Right, that's why I'll be trying to get that consensus.  Us agreeing
among ourselves is just the first step, the second, and much harder is
getting the other consumer (Microsoft) and the BIOS (UEFI/Tianocore
because they're a single entity) communities to follow.

> Though keep in mind, tt doesn't prevent physical access from
> manipulating the PCRs, it just makes it more expensive than one wire
> and a microscope. Maybe it now involves de-soldering, etc.

Sure ... but at least we're moving back to only well funded entities
and nation states, not just the average hacker in the street ...

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 17:23   ` James Bottomley
@ 2018-11-20 23:12     ` Jarkko Sakkinen
  0 siblings, 0 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-20 23:12 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 09:23:01AM -0800, James Bottomley wrote:
> On Tue, 2018-11-20 at 13:10 +0200, Jarkko Sakkinen wrote:
> [...]
> > This is basically rewrite of TPM genie paper with extras. just
> > shorten it to include the proposed architecture and point to the TPM
> > Genie paper (which is not in the references at all ATM).
> 
> I really don't think so.  The paper only gives details of bound
> authorization sessions for TPM 2.0 which suffer from no to weak entropy
> problems.  The reason for using salted ones in the document, which
> aren't mentioned at all in the genie paper, is so we have a high
> entropy cryptographically unguessable HMAC and encryption key.

Point taken.

I will re-read the paper with care as soon as I have time and give
better feedback.

> Only if you have some type of security seal, which most laptops don't
> have.

Agreed went over the top on this one.

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 17:25     ` James Bottomley
@ 2018-11-20 23:13       ` Jarkko Sakkinen
  2018-11-20 23:58         ` James Bottomley
  2018-11-21  5:42         ` Jason Gunthorpe
  0 siblings, 2 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-20 23:13 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 09:25:43AM -0800, James Bottomley wrote:
> On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:
> > On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
> > > This is basically rewrite of TPM genie paper with extras. Maybe
> > > just shorten it to include the proposed architecture and point to
> > > the TPM Genie paper (which is not in the references at all ATM).
> > > 
> > > The way I see it the data validation is way more important than
> > > protecting against physical interposer to be frank.
> > > 
> > > The attack scenario would require to open the damn device. For
> > > laptop that would leave physical marks (i.e. evil maid). In a data
> > > center with armed guards I would wish you good luck accomplishing
> > > it. It is not anything like sticking a USB stick and run.
> > > 
> > > We can take a fix into Linux with a clean implementation but it
> > > needs to be an opt-in feature because not all users will want to
> > > use it.
> > 
> > Someone (might have been either Mimi or David Howells but cannot
> > recall) correctly pointed out at LSS 2018 that you could just as
> > easily spy and corrupt RAM if you have a time window to perform this
> > type of attack.
> 
> Not using the simple plug in on the TPM bus, you can't.  The point is
> basically the difference in the technology: the interposer is a simple,
> easy to construct, plugin; a RAM spy is a huge JTAG thing that would be
> hard even to fit into a modern thin laptop, let alone extremely
> difficult to build.

Why you wouldn't use DMA to spy the RAM?

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 22:34                       ` James Bottomley
@ 2018-11-20 23:39                         ` Jason Gunthorpe
  2018-11-21  2:24                           ` EXTERNAL: " Jeremy Boone
  0 siblings, 1 reply; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-20 23:39 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, Jarkko Sakkinen,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 02:34:52PM -0800, James Bottomley wrote:

> https://trustedcomputinggroup.org/resource/implementing-hardware-roots-of-trust/

Notice none of their examples include 'prevent tampering with the
hardware' all are focused on pure software attacks, which the TPM is
excellent at preventing. The TPM was never supposed to prevent
physical attacks against the HW for the PCR feature.

The only HW guarentee it ever provided is to prevent theft of the
private secrets, even with physical access.

> > It doesn't need contact with the CPU. The basic flow would be to use
> > the interposer on SPI or LPC to block the Nth PCR update, having
> > determined that Nth comes from the BIOS and covers the
> > bootloader.. The BIOS ignores the error, or can't tell the PCR update
> > was corrupted. From there it is easy to see how to get into a hostile
> > kernel and extend the PCRs to match a trusted kernel.
> 
> Right, but that's why I want to detect the error and shut down the TPM.

Well, I think this is a lot of industry effort and still leaves open
other fairly simple physical attacks, like wire-to-the-reset.

I can always make an interposer that did wire-to-the-reset, I don't
need to do complicated dynamic things with PCR extend commands.

And the null key doesn't really protect against wire-to-the-reset, as
the null key doesn't participate in the PCR extend. So
unseal/seal/attest commands don't know if the TPM was booted
authentically or via a wire-to-the-reset and a hostile kernel.

Yes, it lets a trusted kernel detect a problem, but a threat model
that includes an interposer and excludes a hostile kernel doesn't
sound so interesting to me???

Like I said at the start, the way the spec is written, PCR requires
trusted HW. Without a TPM spec change we can't fix this basic
assumption.

A better mitigation to the interposer threat is for PCB manufactures
to use BGA packages, blind vias and internal traces to physically deny
easy access to the TPM bus and reset signal.

The last TPM project I worked on took physical security into account
when designing the PCB and TPM chip placement, others should do the
same :)

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 17:17                   ` James Bottomley
  2018-11-20 21:33                     ` Jason Gunthorpe
@ 2018-11-20 23:41                     ` Jarkko Sakkinen
  1 sibling, 0 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-20 23:41 UTC (permalink / raw)
  To: James Bottomley
  Cc: Jason Gunthorpe, linux-integrity, linux-security-module,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 09:17:59AM -0800, James Bottomley wrote:
> OK, the TPM is supposed to provide attestation of the correct
> environment on a device under someone else's control (the classic
> example is laptop provided by a company to an employee).  The device is
> under the physical control of the entity you don't entirely trust so
> the TPM is supposed to attest that they're running an approved OS ...
> we have whole TCG specs for that situation.

For me the classic scenario would be more like protecting the employee
that you have given confidential data from 3rd party adversaries.  If an
employee that you get confidential data is in fact an adversary, you are
screwed. Even if the device is untampered.

Having less likely untampered device would still be for better direction
against 3rd party adversaries but alone this does not really solve the
puzzle.

There are technologies like ARM TZ and Intel SGX to provide more secure
host side. But if you have such technologies available you can use them
to run the whole TPM and the problem is solved (at least TZ is used for
this today and you could use SGX to do the same).

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 21:33                     ` Jason Gunthorpe
  2018-11-20 22:34                       ` James Bottomley
@ 2018-11-20 23:52                       ` Jarkko Sakkinen
  1 sibling, 0 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-20 23:52 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: James Bottomley, linux-integrity, linux-security-module,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 02:33:45PM -0700, Jason Gunthorpe wrote:
> So it really is essential that all steps, including the BIOS use
> secure PCR updates, or you may as well not bother in Linux, at least
> for security reasons.
> 
> And I think you were on the right track, the TPM should have a
> per-boot authorization that flows through all layers of the TPM stack
> and guarantees the TPM hasn't been rebooted and with crypto prevents
> lost PCR updates. 
> 
> But that does require standardization, as we do need the BIOS to
> participate.

These talks were already started before LSS 2018 on chat session.
The idea would be to promote the same approach for BIOS.

I see what James is doing a piece, not a full solution but you
have to start from somewhere.

As an opt-in feature it should be ok.

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 23:13       ` Jarkko Sakkinen
@ 2018-11-20 23:58         ` James Bottomley
  2018-11-21  0:33           ` EXTERNAL: " Jeremy Boone
  2018-11-21  6:37           ` Jarkko Sakkinen
  2018-11-21  5:42         ` Jason Gunthorpe
  1 sibling, 2 replies; 34+ messages in thread
From: James Bottomley @ 2018-11-20 23:58 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett

On Wed, 2018-11-21 at 01:13 +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 20, 2018 at 09:25:43AM -0800, James Bottomley wrote:
> > On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:
> > > On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
> > > > This is basically rewrite of TPM genie paper with extras. Maybe
> > > > just shorten it to include the proposed architecture and point
> > > > to the TPM Genie paper (which is not in the references at all
> > > > ATM).
> > > > 
> > > > The way I see it the data validation is way more important than
> > > > protecting against physical interposer to be frank.
> > > > 
> > > > The attack scenario would require to open the damn device. For
> > > > laptop that would leave physical marks (i.e. evil maid). In a
> > > > data center with armed guards I would wish you good luck
> > > > accomplishing it. It is not anything like sticking a USB stick
> > > > and run.
> > > > 
> > > > We can take a fix into Linux with a clean implementation but it
> > > > needs to be an opt-in feature because not all users will want
> > > > to use it.
> > > 
> > > Someone (might have been either Mimi or David Howells but cannot
> > > recall) correctly pointed out at LSS 2018 that you could just as
> > > easily spy and corrupt RAM if you have a time window to perform
> > > this type of attack.
> > 
> > Not using the simple plug in on the TPM bus, you can't.  The point
> > is basically the difference in the technology: the interposer is a
> > simple, easy to construct, plugin; a RAM spy is a huge JTAG thing
> > that would be hard even to fit into a modern thin laptop, let alone
> > extremely difficult to build.
> 
> Why you wouldn't use DMA to spy the RAM?

You mean from a plugin on the TPM bus? most of the buses the TPM is on
don't get DMA access.  Some of them barely get interrupts, which is why
we waste a lot of time polling in TPM drivers.

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: EXTERNAL: Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 23:58         ` James Bottomley
@ 2018-11-21  0:33           ` Jeremy Boone
  2018-11-21  6:37           ` Jarkko Sakkinen
  1 sibling, 0 replies; 34+ messages in thread
From: Jeremy Boone @ 2018-11-21  0:33 UTC (permalink / raw)
  To: James Bottomley
  Cc: Jarkko Sakkinen, linux-integrity, linux-security-module,
	monty.wiseman, Monty Wiseman, Matthew Garrett

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



> On Nov 20, 2018, at 6:58 PM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
>> On Wed, 2018-11-21 at 01:13 +0200, Jarkko Sakkinen wrote:
>>> On Tue, Nov 20, 2018 at 09:25:43AM -0800, James Bottomley wrote:
>>>> On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:
>>>>> On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
>>>>> This is basically rewrite of TPM genie paper with extras. Maybe
>>>>> just shorten it to include the proposed architecture and point
>>>>> to the TPM Genie paper (which is not in the references at all
>>>>> ATM).
>>>>> 
>>>>> The way I see it the data validation is way more important than
>>>>> protecting against physical interposer to be frank.
>>>>> 
>>>>> The attack scenario would require to open the damn device. For
>>>>> laptop that would leave physical marks (i.e. evil maid). In a
>>>>> data center with armed guards I would wish you good luck
>>>>> accomplishing it. It is not anything like sticking a USB stick
>>>>> and run.
>>>>> 
>>>>> We can take a fix into Linux with a clean implementation but it
>>>>> needs to be an opt-in feature because not all users will want
>>>>> to use it.
>>>> 
>>>> Someone (might have been either Mimi or David Howells but cannot
>>>> recall) correctly pointed out at LSS 2018 that you could just as
>>>> easily spy and corrupt RAM if you have a time window to perform
>>>> this type of attack.
>>> 
>>> Not using the simple plug in on the TPM bus, you can't.  The point
>>> is basically the difference in the technology: the interposer is a
>>> simple, easy to construct, plugin; a RAM spy is a huge JTAG thing
>>> that would be hard even to fit into a modern thin laptop, let alone
>>> extremely difficult to build.
>> 
>> Why you wouldn't use DMA to spy the RAM?
> 
> You mean from a plugin on the TPM bus? most of the buses the TPM is on
> don't get DMA access.  Some of them barely get interrupts, which is why
> we waste a lot of time polling in TPM drivers.

You can do DMA over the LPC bus if you pull down the LDRQ pin. But typically that pin isn’t populated on the TPM header on mainboards. I suppose this may be intentional. 

> 
> James
> 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2703 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: EXTERNAL: Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 23:39                         ` Jason Gunthorpe
@ 2018-11-21  2:24                           ` Jeremy Boone
  2018-11-21  5:16                             ` Jason Gunthorpe
  0 siblings, 1 reply; 34+ messages in thread
From: Jeremy Boone @ 2018-11-21  2:24 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: James Bottomley, linux-integrity, linux-security-module,
	Jarkko Sakkinen, monty.wiseman, Monty Wiseman, Matthew Garrett

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



> On Nov 20, 2018, at 6:39 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> 
>> On Tue, Nov 20, 2018 at 02:34:52PM -0800, James Bottomley wrote:
>> 
>> https://protect-eu.mimecast.com/s/D_7bCj2BliYEYn0TWDV1q
> 
> Notice none of their examples include 'prevent tampering with the
> hardware' all are focused on pure software attacks, which the TPM is
> excellent at preventing. The TPM was never supposed to prevent
> physical attacks against the HW for the PCR feature.
> 
> The only HW guarentee it ever provided is to prevent theft of the
> private secrets, even with physical access.
> 
>>> It doesn't need contact with the CPU. The basic flow would be to use
>>> the interposer on SPI or LPC to block the Nth PCR update, having
>>> determined that Nth comes from the BIOS and covers the
>>> bootloader.. The BIOS ignores the error, or can't tell the PCR update
>>> was corrupted. From there it is easy to see how to get into a hostile
>>> kernel and extend the PCRs to match a trusted kernel.
>> 
>> Right, but that's why I want to detect the error and shut down the TPM.
> 
> Well, I think this is a lot of industry effort and still leaves open
> other fairly simple physical attacks, like wire-to-the-reset.
> 
> I can always make an interposer that did wire-to-the-reset, I don't
> need to do complicated dynamic things with PCR extend commands.
> 
> And the null key doesn't really protect against wire-to-the-reset, as
> the null key doesn't participate in the PCR extend. So
> unseal/seal/attest commands don't know if the TPM was booted
> authentically or via a wire-to-the-reset and a hostile kernel.
> 
> Yes, it lets a trusted kernel detect a problem, but a threat model
> that includes an interposer and excludes a hostile kernel doesn't
> sound so interesting to me???

The idea is that if the bootloader(s) also protect the bus transactions with an HMAC, then we could detect tampering and before ever booting into a hostile kernel.

> 
> Like I said at the start, the way the spec is written, PCR requires
> trusted HW. Without a TPM spec change we can't fix this basic
> assumption.
> 
> A better mitigation to the interposer threat is for PCB manufactures
> to use BGA packages, blind vias and internal traces to physically deny
> easy access to the TPM bus and reset signal.

Yes. I said as much in the TPM Genie paper. A firmware TPM is even better, as we never need to worry about protecting the bus because it is never exposed in the first place. 

> 
> The last TPM project I worked on took physical security into account
> when designing the PCB and TPM chip placement, others should do the
> same :)
> 
> Jason
> 

I think it’s worth recognizing that TPMs are used in a variety of deployments, each with their own unique threat model and attack surface. 

For example, some users may care about evil maid scenarios. Heck, TPM-TOTP (and dare I mention the Qubes Anti-Evil Maid technology) utilizes the TPM to attest the boot state to the device owner. 

Other users may care about the “lost in the back of a taxi” scenario wherein the attacker may have extended physical access to the mobile device (a phone or laptop) before returning it to the owner. 

In other scenarios, the device user may be a different entity than the device owner, and as such, different security considerations must be applied. Think of a set top box that you’ve rented from your cable service provider which uses a TPM to remotely attest the firmware before being trusted to handle content decryption keys. Or a car share program that uses the TPM as a means to store temporary keyless-entry tokens — After all, the TCG Automotive Thin Profile is taking off, as are the SAE J3101 requirements which suggest the use of TPM in automotive applications.  An interposer, or even a simple sniffer attached to test points on the bus, would be able to observe any secrets transmitted between the TPM and host. 

I believe that the Linux kernel has an obligation to build in active defences that protect TPM users against serial bus attacks, and makes no blind assumptions about the ways in which a TPM may be used or deployed in a variety of creative or unexpected ways. 

This is especially true in light of the fact that the TCG (and TPM chip manufacturers as well) have not plainly documented that, despite having expended considerable effort defending against invasive silicon attacks (see Chris Tarnovsky’s work), a trivial interposer can still defeat TPM security. I believe that many do not understand this fact, and conflate the idea that measured boot can detect “hardware tampering” vs. mere “firmware tampering”. Regardless, it seems odd to me that we wish to defend against one-off attacks involving an electron microscope, but do not wish to defend against a simple microcontroller acting as a man-in-the-middle on the bus. 

It’s true that with sufficient time and motivation, a dedicated and well-funded adversary can defeat almost any protection mechanism. But our job as defenders is to raise the bar so that cheap and inexpensive attacks are no longer feasible. By raising the cost of exploitation beyond the adversary’s appetite, we eliminate entire classes of attack.

Choosing to do nothing simply because other attack avenues exist is a little too defeatist of an attitude for me. Especially given that the TPM specification does support payload encryption and integrity protection through the use of Authorization Sessions. So we do have the necessary tools to begin to solve this problem. Unfortunately, it is also true that this issue extends beyond the kernel. We also need to land similar patches for every stage of the boot process that performs a PCR Extend operation. Otherwise the chain of trust can be broken before the kernel is even started. 

All that said, I’m pretty invested in TPM Genie, so I am obviously biased towards seeing a fix. 

Jeremy

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2703 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: EXTERNAL: Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-21  2:24                           ` EXTERNAL: " Jeremy Boone
@ 2018-11-21  5:16                             ` Jason Gunthorpe
  0 siblings, 0 replies; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-21  5:16 UTC (permalink / raw)
  To: Jeremy Boone
  Cc: James Bottomley, linux-integrity, linux-security-module,
	Jarkko Sakkinen, monty.wiseman, Monty Wiseman, Matthew Garrett

On Wed, Nov 21, 2018 at 02:24:18AM +0000, Jeremy Boone wrote:

> I think it’s worth recognizing that TPMs are used in a variety of
> deployments, each with their own unique threat model and attack
> surface.
> 
> For example, some users may care about evil maid scenarios. Heck,
> TPM-TOTP (and dare I mention the Qubes Anti-Evil Maid technology)
> utilizes the TPM to attest the boot state to the device owner.
> 
> Other users may care about the “lost in the back of a taxi” scenario
> wherein the attacker may have extended physical access to the mobile
> device (a phone or laptop) before returning it to the owner.
> 
> In other scenarios, the device user may be a different entity than
> the device owner, and as such, different security considerations
> must be applied. Think of a set top box that you’ve rented from your
> cable service provider which uses a TPM to remotely attest the
> firmware before being trusted to handle content decryption keys. Or
> a car share program that uses the TPM as a means to store temporary
> keyless-entry tokens — After all, the TCG Automotive Thin Profile is
> taking off, as are the SAE J3101 requirements which suggest the use
> of TPM in automotive applications.

> An interposer, or even a simple
> sniffer attached to test points on the bus, would be able to observe
> any secrets transmitted between the TPM and host.

Not quite, it is not 'any' secrets. We can and absolutely should
competently encrypt various things, like shared secrets for unlocking
keys private data to be seal/unsealed, etc. There are robust working
mechanisms for this already in the spec.

I think this is very important and I know I've always coded my TPM
implementations to make use of these features.

But PCR extend is not private data, the data is well known.

> I believe that the Linux kernel has an obligation to build in active
> defences that protect TPM users against serial bus attacks, and
> makes no blind assumptions about the ways in which a TPM may be used
> or deployed in a variety of creative or unexpected ways.
> 
> This is especially true in light of the fact that the TCG (and TPM
> chip manufacturers as well) have not plainly documented that,
> despite having expended considerable effort defending against
> invasive silicon attacks (see Chris Tarnovsky’s work), a trivial
> interposer can still defeat TPM security. I believe that many do not
> understand this fact, and conflate the idea that measured boot can
> detect “hardware tampering” vs. mere “firmware
> tampering”. 

This is basically my concern. HMACing the PCRs does not magically
allow measured boot to detect "hardware tampering". Even if all layers
from the BIOS down do this correctly. Pretending otherwise continues
to push the incorrect message that PCRs do anything beyond detecting
"firmware tampering", as you say.

> Regardless, it seems odd to me that we wish to defend against
> one-off attacks involving an electron microscope, but do not wish to
> defend against a simple microcontroller acting as a
> man-in-the-middle on the bus.

I agree with this, but if you want to defent against hardware
tampering then one should defend robustly against all hardware
tampering and call that a TPM capability. A half implemented hardware
tampering defence only gives a false sense of security.

I think it is possible to do, but it requires some updates to the TPM
specification.

A general proposal would go something like...

1) The TPM gains a new NV flag 'Secure Reset Required' and a new command
   'Secure Reset'
2) Issuing the'Secure Reset' command requires the TPM and CPU to both
   prove to each other they are authentic, using some crypto protocol
   (lots of options here)
2a) The TPM will store it's private secret for #2 either as a loaded blob
    against a NV key or in NV itself. There is some protocol during
    owning that allows the BIOS to initialize this stuff and set
    Secure Reset Required. Maybe we assume the HW is untampered during
    owning.
2b) The CPU will store its private secret for #2 encrypted using modern
    CPU encryption technology like Intel's SGX, or similar. The
    encrypted key will be stored in BIOS flash.
3) Upon boot the CPU will securely decrypt it's secret and issue
   'Secure Reset'. The TPM will not function until this command is
   issued. The only other option is a complete wipe.
4) During the 'Secure Reset' crypto the two sides will exchange
   trusted or secret information used to authenticate and encrypt
   all future communications
5) The BIOS will pass the #4 data down to the bootloader and to the
   kernel for use when executign TPM commands, or maybe the BIOS will
   transparently link it into the ACPI CRB executor or something.
6) TPM will reject any unathenticated&encrypted packet after Secure Reset

Now we have properly defended against a wide range of HW
tampering. You can't snoop/hijack the TPM bus. You can't reset the
TPM. You can't hack the BIOS FLASH and take over the BIOS before TPM
reset (assuming SGX is implemented properly). You can't replace the
trusted CPU with a hostile CPU. You can't desolder the TPM. This is an
excellent improvement in HW defense. If the SGX code also sets up DRAM
encryption then we are getting to be really properly secured against
HW tampering.

This is sort of what I mean when I say a spec update is needed. The
spec needs to be designed to properly detect and combat HW tampering.
We can't add this new feature robustly with only the functional
elements already in the spec.

[Of course this is kind of a silly thing to do, because if you have
 this CPU technology then you may was well just implement the TPM in
 the CPU.. But this is more of a thought experiment as to what would be
 needed to secure a discrete TPM against HW tampering]

> It’s true that with sufficient time and motivation, a dedicated and
> well-funded adversary can defeat almost any protection
> mechanism. But our job as defenders is to raise the bar so that
> cheap and inexpensive attacks are no longer feasible. By raising the
> cost of exploitation beyond the adversary’s appetite, we eliminate
> entire classes of attack.

My concern is we haven't done this simply because the reset-line
attack is less cost and complexity than the interposer on the data bus
attack, so we must prevent it first and foremost. Then prevent data
bus mangling, then prevent loading modified BIOS's, then prevent
hacked CPUs, and so on until things become properly expensive.

> Choosing to do nothing simply because other attack avenues exist is
> a little too defeatist of an attitude for me. Especially given that
> the TPM specification does support payload encryption and integrity
> protection through the use of Authorization Sessions. 

We absolutely should be using encrypted and authenticated sessions
when transporting any secret data.

> So we do have the necessary tools to begin to solve this
> problem. Unfortunately, it is also true that this issue extends
> beyond the kernel. We also need to land similar patches for every
> stage of the boot process that performs a PCR Extend
> operation. Otherwise the chain of trust can be broken before the
> kernel is even started.

Right, but this chain of trust starts at the reset line, not at the
BIOS. There is language in the spec requiring the platform to control
the reset line along with the CPU reset - this is critically necessary
to make PCRs work for 'measured boot'.

In my mind an interposer also means hostile control over the reset
line, so reset protection must be part of any complete defence against
an interposer.

The idea James had with the null key to detect reset doesn't mitigate
the case where hostile code is running on the CPU along with an
interposer. We can't make the assumption that only trusted code is
running in the CPU - if we could assume that we wouldn't need PCRs and
measured boot in the first place. ;)

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 23:13       ` Jarkko Sakkinen
  2018-11-20 23:58         ` James Bottomley
@ 2018-11-21  5:42         ` Jason Gunthorpe
  2018-11-21  7:18           ` Jarkko Sakkinen
  1 sibling, 1 reply; 34+ messages in thread
From: Jason Gunthorpe @ 2018-11-21  5:42 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: James Bottomley, linux-integrity, linux-security-module,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Wed, Nov 21, 2018 at 01:13:20AM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 20, 2018 at 09:25:43AM -0800, James Bottomley wrote:
> > On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:
> > > On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
> > > > This is basically rewrite of TPM genie paper with extras. Maybe
> > > > just shorten it to include the proposed architecture and point to
> > > > the TPM Genie paper (which is not in the references at all ATM).
> > > > 
> > > > The way I see it the data validation is way more important than
> > > > protecting against physical interposer to be frank.
> > > > 
> > > > The attack scenario would require to open the damn device. For
> > > > laptop that would leave physical marks (i.e. evil maid). In a data
> > > > center with armed guards I would wish you good luck accomplishing
> > > > it. It is not anything like sticking a USB stick and run.
> > > > 
> > > > We can take a fix into Linux with a clean implementation but it
> > > > needs to be an opt-in feature because not all users will want to
> > > > use it.
> > > 
> > > Someone (might have been either Mimi or David Howells but cannot
> > > recall) correctly pointed out at LSS 2018 that you could just as
> > > easily spy and corrupt RAM if you have a time window to perform this
> > > type of attack.
> > 
> > Not using the simple plug in on the TPM bus, you can't.  The point is
> > basically the difference in the technology: the interposer is a simple,
> > easy to construct, plugin; a RAM spy is a huge JTAG thing that would be
> > hard even to fit into a modern thin laptop, let alone extremely
> > difficult to build.
> 
> Why you wouldn't use DMA to spy the RAM?

The platform has to use IOMMU to prevent improper DMA access from
places like PCI-E slots if you are using measured boot and want to
defend against HW tampering.

The BIOS has to sequence things so that at least pluggable PCI-E slots
cannot do DMA until the IOMMU is enabled.

Honestly not sure if we do this all correctly in Linux, or if BIOS
vendors even implemented this level of protection. The BIOS would have
to leave the PCI-E root port slots disabled, and configure the ports
to reject config TLPs from the hostile PCI-E device, and probably a
big bunch of other stuff.. Then Linux would have to enable the IOMMU
and then enable the PCI-E ports for operation.

Pretty subtle and tricky stuff.

Without IOMMU it would be trivial to plug a card in an open PCI-E slot
(or M.2 slot on a laptop) and breach all measured boot guarantees via
DMA. For instance, if IOMMU is not enabled during grub then I could
overwrite the trusted grub with DMA and cleverly make it jump to my
hostile code, then I can replay PCR extends to the TPM and
seal/unseal/attest using the PCRs set to a trusted sytem when running
hostile code. Oopsie.

This is a much easier attack than inserting a TPM interposer or
messing with the TPM reset line...

But again, measured boot does not protect against HW tampering, so
this is probably not included in the threat model the BIOS uses...

Jason

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-20 23:58         ` James Bottomley
  2018-11-21  0:33           ` EXTERNAL: " Jeremy Boone
@ 2018-11-21  6:37           ` Jarkko Sakkinen
  1 sibling, 0 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-21  6:37 UTC (permalink / raw)
  To: James Bottomley
  Cc: linux-integrity, linux-security-module, monty.wiseman,
	Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 03:58:51PM -0800, James Bottomley wrote:
> On Wed, 2018-11-21 at 01:13 +0200, Jarkko Sakkinen wrote:
> > On Tue, Nov 20, 2018 at 09:25:43AM -0800, James Bottomley wrote:
> > > On Tue, 2018-11-20 at 14:41 +0200, Jarkko Sakkinen wrote:
> > > > On Tue, Nov 20, 2018 at 01:10:49PM +0200, Jarkko Sakkinen wrote:
> > > > > This is basically rewrite of TPM genie paper with extras. Maybe
> > > > > just shorten it to include the proposed architecture and point
> > > > > to the TPM Genie paper (which is not in the references at all
> > > > > ATM).
> > > > > 
> > > > > The way I see it the data validation is way more important than
> > > > > protecting against physical interposer to be frank.
> > > > > 
> > > > > The attack scenario would require to open the damn device. For
> > > > > laptop that would leave physical marks (i.e. evil maid). In a
> > > > > data center with armed guards I would wish you good luck
> > > > > accomplishing it. It is not anything like sticking a USB stick
> > > > > and run.
> > > > > 
> > > > > We can take a fix into Linux with a clean implementation but it
> > > > > needs to be an opt-in feature because not all users will want
> > > > > to use it.
> > > > 
> > > > Someone (might have been either Mimi or David Howells but cannot
> > > > recall) correctly pointed out at LSS 2018 that you could just as
> > > > easily spy and corrupt RAM if you have a time window to perform
> > > > this type of attack.
> > > 
> > > Not using the simple plug in on the TPM bus, you can't.  The point
> > > is basically the difference in the technology: the interposer is a
> > > simple, easy to construct, plugin; a RAM spy is a huge JTAG thing
> > > that would be hard even to fit into a modern thin laptop, let alone
> > > extremely difficult to build.
> > 
> > Why you wouldn't use DMA to spy the RAM?
> 
> You mean from a plugin on the TPM bus? most of the buses the TPM is on
> don't get DMA access.  Some of them barely get interrupts, which is why
> we waste a lot of time polling in TPM drivers.

No. I that if you get physical access you can do all sorts of other
stuff in the host side. It doesn't matter how secure the path between
the host and TPM is.

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-21  5:42         ` Jason Gunthorpe
@ 2018-11-21  7:18           ` Jarkko Sakkinen
       [not found]             ` <F10185EF-C618-45DC-B1F3-0053B8FE417F@gmail.com>
  2018-11-21  9:14             ` Jarkko Sakkinen
  0 siblings, 2 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-21  7:18 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: James Bottomley, linux-integrity, linux-security-module,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Tue, Nov 20, 2018 at 10:42:01PM -0700, Jason Gunthorpe wrote:
> > Why you wouldn't use DMA to spy the RAM?
> 
> The platform has to use IOMMU to prevent improper DMA access from
> places like PCI-E slots if you are using measured boot and want to
> defend against HW tampering.

Yes. This is what I wanted to point out. Windows 10 has VBS to
achieve something like this.

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs

> The BIOS has to sequence things so that at least pluggable PCI-E slots
> cannot do DMA until the IOMMU is enabled.

Yep.

> Honestly not sure if we do this all correctly in Linux, or if BIOS
> vendors even implemented this level of protection. The BIOS would have
> to leave the PCI-E root port slots disabled, and configure the ports
> to reject config TLPs from the hostile PCI-E device, and probably a
> big bunch of other stuff.. Then Linux would have to enable the IOMMU
> and then enable the PCI-E ports for operation.

Linux should have something like VBS. Like James' proposal it does not
solve the puzzle but is one step forward...

> Pretty subtle and tricky stuff.
> 
> Without IOMMU it would be trivial to plug a card in an open PCI-E slot
> (or M.2 slot on a laptop) and breach all measured boot guarantees via
> DMA. For instance, if IOMMU is not enabled during grub then I could
> overwrite the trusted grub with DMA and cleverly make it jump to my
> hostile code, then I can replay PCR extends to the TPM and
> seal/unseal/attest using the PCRs set to a trusted sytem when running
> hostile code. Oopsie.
> 
> This is a much easier attack than inserting a TPM interposer or
> messing with the TPM reset line...
> 
> But again, measured boot does not protect against HW tampering, so
> this is probably not included in the threat model the BIOS uses...

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
       [not found]             ` <F10185EF-C618-45DC-B1F3-0053B8FE417F@gmail.com>
@ 2018-11-21  9:07               ` Jarkko Sakkinen
  0 siblings, 0 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-21  9:07 UTC (permalink / raw)
  To: Rich Persaud
  Cc: Jason Gunthorpe, James Bottomley, linux-integrity,
	linux-security-module, monty.wiseman, Monty Wiseman,
	Matthew Garrett, Trammell Hudson, Daniel Smith,
	Marek Marczykowski-Górecki

On Wed, Nov 21, 2018 at 03:08:51AM -0500, Rich Persaud wrote:
>    On Nov 21, 2018, at 02:18, Jarkko Sakkinen
>    <jarkko.sakkinen@linux.intel.com> wrote:
> 
>      On Tue, Nov 20, 2018 at 10:42:01PM -0700, Jason Gunthorpe wrote:
> 
>          Why you wouldn't use DMA to spy the RAM?
> 
>        The platform has to use IOMMU to prevent improper DMA access from
> 
>        places like PCI-E slots if you are using measured boot and want to
> 
>        defend against HW tampering.
> 
>      Yes. This is what I wanted to point out. Windows 10 has VBS to
>      achieve something like this.
>      https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs
> 
>        The BIOS has to sequence things so that at least pluggable PCI-E slots
> 
>        cannot do DMA until the IOMMU is enabled.
> 
>      Yep.
> 
>        Honestly not sure if we do this all correctly in Linux, or if BIOS
> 
>        vendors even implemented this level of protection. The BIOS would have
> 
>        to leave the PCI-E root port slots disabled, and configure the ports
> 
>        to reject config TLPs from the hostile PCI-E device, and probably a
> 
>        big bunch of other stuff.. Then Linux would have to enable the IOMMU
> 
>        and then enable the PCI-E ports for operation.
> 
>      Linux should have something like VBS. Like James' proposal it does not
>      solve the puzzle but is one step forward...
> 
>    Qubes OS and OpenXT [1][2] can use Linux, Xen, IOMMU and DRTM for boot
>    integrity and PCI device isolation.  They preceded VBS by several years
>    [3].  Trammell's talk, "Firmware is the new Software" [4] and work on
>    Heads [5][6] is also relevant.
>    Rich
>    1.  https://www.platformsecuritysummit.com/2018/references/#openxt
>    2.  https://www.platformsecuritysummit.com/2018/topic/boot/
>    3.  https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html
>    4.  https://www.platformsecuritysummit.com/2018/speaker/hudson/
>    5.  https://www.trmm.net/Heads
>    6.  https://puri.sm/posts/the-librem-key-makes-tamper-detection-easy/

Please do not send HTML trashed emails. For more information how to
configure your email client, please refer to:

https://www.kernel.org/doc/Documentation/email-clients.txt

Thank you.

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-21  7:18           ` Jarkko Sakkinen
       [not found]             ` <F10185EF-C618-45DC-B1F3-0053B8FE417F@gmail.com>
@ 2018-11-21  9:14             ` Jarkko Sakkinen
  1 sibling, 0 replies; 34+ messages in thread
From: Jarkko Sakkinen @ 2018-11-21  9:14 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: James Bottomley, linux-integrity, linux-security-module,
	monty.wiseman, Monty Wiseman, Matthew Garrett

On Wed, Nov 21, 2018 at 09:18:19AM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 20, 2018 at 10:42:01PM -0700, Jason Gunthorpe wrote:
> > > Why you wouldn't use DMA to spy the RAM?
> > 
> > The platform has to use IOMMU to prevent improper DMA access from
> > places like PCI-E slots if you are using measured boot and want to
> > defend against HW tampering.
> 
> Yes. This is what I wanted to point out. Windows 10 has VBS to
> achieve something like this.
> 
> https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs

Some trials like Qubes are in existence (uses Xen).

I've been thinking should Linux have a thin hypervisor solely for VBS
like use in order to gain wider adoption.

/Jarkko

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-11-19 17:34 Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks James Bottomley
  2018-11-19 20:05 ` Jason Gunthorpe
  2018-11-20 11:10 ` Jarkko Sakkinen
@ 2018-12-10 16:33 ` Ken Goldman
  2018-12-10 17:30   ` James Bottomley
  2 siblings, 1 reply; 34+ messages in thread
From: Ken Goldman @ 2018-12-10 16:33 UTC (permalink / raw)
  To: James Bottomley, linux-integrity, linux-security-module

On 11/19/2018 12:34 PM, James Bottomley wrote:

> 2. At some point in time the attacker could reset the TPM, clearing
>     the PCRs and then send down their own measurements which would
>     effectively overwrite the boot time measurements the TPM has
>     already done.
> [snip]
> However, the second can only really be detected by relying
> on some sort of mechanism for protection which would change over TPM
> reset.

FYI: TPM 2.0 has a resetCount that can be used to detect, but not 
protect against, this attack.

> Every TPM comes shipped with a couple of X.509 certificates for the
> primary endorsement key.  This document assumes that the Elliptic
> Curve version of the certificate exists at 01C00002, but will work
> equally well with the RSA certificate (at 01C00001).

A nit.  The RSA cert is at 01c00002.  The ECC cert is at 01c0000a.


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-12-10 16:33 ` Ken Goldman
@ 2018-12-10 17:30   ` James Bottomley
  2018-12-11 21:47     ` Ken Goldman
  0 siblings, 1 reply; 34+ messages in thread
From: James Bottomley @ 2018-12-10 17:30 UTC (permalink / raw)
  To: Ken Goldman, linux-integrity, linux-security-module

On Mon, 2018-12-10 at 11:33 -0500, Ken Goldman wrote:
> On 11/19/2018 12:34 PM, James Bottomley wrote:
> 
> > 2. At some point in time the attacker could reset the TPM, clearing
> >     the PCRs and then send down their own measurements which would
> >     effectively overwrite the boot time measurements the TPM has
> >     already done.
> > [snip]
> > However, the second can only really be detected by relying
> > on some sort of mechanism for protection which would change over
> > TPM reset.
> 
> FYI: TPM 2.0 has a resetCount that can be used to detect, but not 
> protect against, this attack.

Yes, but that would be an additional check we'd have to do.  Using the
NULL seed for salt means the HMAC and Encryption on commands instantly
breaks if the TPM is reset.

> > Every TPM comes shipped with a couple of X.509 certificates for the
> > primary endorsement key.  This document assumes that the Elliptic
> > Curve version of the certificate exists at 01C00002, but will work
> > equally well with the RSA certificate (at 01C00001).
> 
> A nit.  The RSA cert is at 01c00002.  The ECC cert is at 01c0000a.

Is this actually published somewhere? ... I was guessing from the TPM
2.0 provisioning guide.

James


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
  2018-12-10 17:30   ` James Bottomley
@ 2018-12-11 21:47     ` Ken Goldman
  0 siblings, 0 replies; 34+ messages in thread
From: Ken Goldman @ 2018-12-11 21:47 UTC (permalink / raw)
  To: James Bottomley, linux-integrity, linux-security-module

On 12/10/2018 12:30 PM, James Bottomley wrote:
>> A nit.  The RSA cert is at 01c00002.  The ECC cert is at 01c0000a.
> Is this actually published somewhere? ... I was guessing from the TPM
> 2.0 provisioning guide.

Yes.

The certificates, including the handles, are standardized
in the Infrastructure WG document: TCG EK Credential Profile
For TPM Family 2.0.

This document also explains how to recreate the EKs from standard templates.


^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2018-12-11 21:46 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-19 17:34 Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks James Bottomley
2018-11-19 20:05 ` Jason Gunthorpe
2018-11-19 20:20   ` James Bottomley
2018-11-19 21:19     ` Jason Gunthorpe
2018-11-19 21:34       ` James Bottomley
2018-11-19 21:44         ` Jason Gunthorpe
2018-11-19 22:36           ` James Bottomley
2018-11-19 23:08             ` Jason Gunthorpe
2018-11-20  0:54               ` James Bottomley
2018-11-20  3:05                 ` Jason Gunthorpe
2018-11-20 17:17                   ` James Bottomley
2018-11-20 21:33                     ` Jason Gunthorpe
2018-11-20 22:34                       ` James Bottomley
2018-11-20 23:39                         ` Jason Gunthorpe
2018-11-21  2:24                           ` EXTERNAL: " Jeremy Boone
2018-11-21  5:16                             ` Jason Gunthorpe
2018-11-20 23:52                       ` Jarkko Sakkinen
2018-11-20 23:41                     ` Jarkko Sakkinen
2018-11-20 11:10 ` Jarkko Sakkinen
2018-11-20 12:41   ` Jarkko Sakkinen
2018-11-20 17:25     ` James Bottomley
2018-11-20 23:13       ` Jarkko Sakkinen
2018-11-20 23:58         ` James Bottomley
2018-11-21  0:33           ` EXTERNAL: " Jeremy Boone
2018-11-21  6:37           ` Jarkko Sakkinen
2018-11-21  5:42         ` Jason Gunthorpe
2018-11-21  7:18           ` Jarkko Sakkinen
     [not found]             ` <F10185EF-C618-45DC-B1F3-0053B8FE417F@gmail.com>
2018-11-21  9:07               ` Jarkko Sakkinen
2018-11-21  9:14             ` Jarkko Sakkinen
2018-11-20 17:23   ` James Bottomley
2018-11-20 23:12     ` Jarkko Sakkinen
2018-12-10 16:33 ` Ken Goldman
2018-12-10 17:30   ` James Bottomley
2018-12-11 21:47     ` Ken Goldman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).