lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090515120748.GF6816@mit.edu>
Date:	Fri, 15 May 2009 08:07:48 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Cihula, Joseph" <joseph.cihula@...el.com>
Cc:	James Morris <jmorris@...ei.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"chrisw@...s-sol.org" <chrisw@...s-sol.org>,
	"jbeulich@...ell.com" <jbeulich@...ell.com>,
	"peterm@...hat.com" <peterm@...hat.com>,
	"Wei, Gang" <gang.wei@...el.com>,
	"Wang, Shane" <shane.wang@...el.com>, John Gilmore <gnu@...d.com>
Subject: Re: [RFC v3][PATCH 2/2] intel_txt: Intel(R) TXT and tboot kernel
	support

On Thu, May 14, 2009 at 06:45:29PM -0700, Cihula, Joseph wrote:
> 
> For a balanced view on Trusted Computing, people should also read
> David Safford's (IBM) rebuttal whitepaper at:
> http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf.

Note that most of what David wrote about in his paper was specific to
TCPA, and not necessarily the TXT/LaGrande technology.  I recently
defended TCPA to someone who expressed concerns about IMA going into
the kernel, on the grounds that TCPA was so badly done it was almost
impossible to use it to create a workable DRM system.  Given how TCPA
works, this is definitely true, and I judge that the benefits (being
able to protect private keys under the user's controlled) outwieghs
the potential downsides (namely that of DRM, given that it was pretty
much impossible to make a workable DRM system using the TCPA/IMA
architecture alone).

However, it seems to me that TXT/LaGrande's main purpose for existence
was to repair the defects in TCPA that made it essentially unsuable
for DRM purposes.  With TCPA, any time you changed *anything* in the
boot path --- installed a new BIOS, upgraded to a new kernel to fix a
security vulnerability, updated to a new Nvidia proprietary video
driver slightly less likely to crash your sustem --- it would change
the trusted boot measurements, and would require an exchange to
"Circuity City DIVX hotline" (as a generic stand-in for whoever is
Hollywood's current monkey paw towards trying to implement DRM) to
approve a transfer of the TCPA trusted keys, which would be
essentially be a consumer support nightmare, and there would be no way
for "Circuit City" to know whether the kernel you are claiming was the
latest update from Fedora or Novell or Canonical was really an
authorized upgrade, or whether it was a custom kernel with patches to
tap into video and audio paths to steal Hollywood's precious bodily
fluids.

With TXT, however, all of these problems go away.  What you end up
booting is completely under "Circit City's DIVX's" control, and may
include a miniature Windows environment running in the trusted
environment; it could then take over a portion of the screen for the
video output, and the hardware would have special features set up to
prevent the host OS from having any access to the video output of the
movie player running in the TXT environment.  (This was how Intel
presented the LaGrande technology to the Kernel Summit several years
ago, and I assume the capabilities of TXT hasn't change significantly
since then.)

Essentially, it's hard for me to think up situations where the TCPA
chip would not be sufficient in terms of being a solution to a
security problem that has the user's best interests at heart, rather
than that of Hollywood, and where TXT would be a such a solution.
Medical records are perhaps the best example I can come up with; and
maybe some kind of bank security system where you're only allowed to
engage in on-line banking if you run a bank-supplied application in
the TXT environment.  However, it's hard for me to believe banks and
hospitals will invest in solutions that implement these sorts of
benign solutions, and it's all too easy for me to believe that
Hollywood will invest in these sorts of solutions.

That being said, it's not clear to me that stopping the technology
from going into Linux really isn't going to help matters;
realistically, the Linux desktop is miniscule[1], and whether or not
we add support for TXT in the mainline Linux kernel isn't going to
stop Hollywood's plans.  A much better approach would be for the FSF
to organize a boycott urging users users not to buy *any* hardware
that is TXT enabled, whether it is going to be booting Windows, MacOS
X, or Linux.  And note that I said *hardware*, not CPU.  In order for
TXT to work, the BIOS, motherboard, video chipset, etc., all have to
be working in concert in order to provide a secure environment that
can't be tapped in by the Host OS.

[1] The one potential risk I could see is TXT being used in Moblin,
and that being used as a scheme to implement DRM ala Hollywood style.
But realistically, even if we don't let it into mainline kernel, it
won't stop Moblin hardware vendors from shipping it.

The bottom line is it this is a social problem, not a technical
problem, and probably needs to be solved by social means (i.e., an
FSF-led boycott).  But from a technical point of view, I would be
shocked if the first major user of the TXT technology *wasn't* to
provide DRM enforcement of one kind or another.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ