

Prevent cold boot attacks using TRESOR - thomas-st
http://www1.informatik.uni-erlangen.de/tresor

======
rdl
TreVisor and TRESOR are some of the most amazing things going on. Combine that
with QUBES out of Invisible Things, and you could conceivably trust a computer
built of untrustworthy hardware operated by your worst adversary, as long as
you trust a tiny subset of it -- potentially just the Intel CPU.

The nice thing about trusting just a latest-edition Intel CPU is that they're
so far ahead of everyone else in process that most attacks would be
technically difficult for anyone except Intel, NSA, etc. Chris Tarnovsky isn't
going to be able to extract keys out of Intel E5 CPUs in 6 hours with even a
10x bigger than $1.5mm lab, so as long as you deal with a machine which
disappears faster than 6h (rotating keys, releasing the hounds, etc.), you
should be safe.

One of the few things (along with the takeover of mobile OSes vs. legacy
crappy desktop OSes) which makes me hopeful for security.

~~~
JoachimSchipper
I'm not dissing TRESOR, which is really neat, but your "build a trusted
machine out of untrusted parts" is _very_ overblown. Among many, many other
problems, neither TRESOR nor QUBES protects you from a compromised
bootloader/BIOS, neither TRESOR nor QUBES protects you from a hardware
keylogger, and neither TRESOR nor QUBES protects you from malicious or
compromised PCI devices. (Also, TRESOR apparently uses passwords - people
cannot be trusted to choose good passwords.)

~~~
pgeorgi
TRESOR or QUBES don't protect from compromised bootloader/BIOS. coreboot does
(and I'm working on it for that reason).

But you can't use current generation Intel CPUs as devised by the GP since
those (or rather their chipsets) come with embedded controllers (running
updateable code signed by someone else) with way too much access to the
hardware to be trustworthy.

To protect against malicious PCI devices use an IOMMU set up early (eg. while
still running code from flash)

There are also facilities against hardware keyloggers, but with today's
hardware integration, that's mostly a matter of physically locking down the
notebook chassis.

~~~
rdl
What would it take to get Coreboot people to support some modern server
motherboards? Ideally, Dell R720 or HP DL160 or an intel reference E5 design.

~~~
pgeorgi
Access to specifications and access to the hardware.

For coreboot, the hard bit is chipset support. With full specs, a device to
work on, and having lowlevel coding experience (not necessarily coreboot),
this is an effort of 3-6 months (depends on specs, on how complex the hardware
is, and a bit of luck).

Once a chipset is supported, adding more boards is relatively easy.

The main issue is that specs are generally under NDA. It varies by vendor how
hard it is to obtain: nVidia is near impossible (the nVidia support we have
was sheer luck), Intel rather wants to see us go away (or so it seems), Via
can be coerced to give specs to individuals, AMD provides code and specs.

For servers, there's the additional complication of LOM - I'm not sure how
hard that would be to support, and I guess vendors vary wildly in how they
hook that up to the system.

About Intel E5: We have sandybridge support (contributed by the chromebook
team), but I don't know how much Intel changed between the consumer
sandybridge and the Xeon stuff. It's also harder to adapt since it uses
Intel's reference code as binary component (probably the best they could get
out of them).

------
gingerlime
Sounds interesting. Very clever thinking.

Just hope it doesn't get turned on its head for some yet-another layer of DRM
that stops us from accessing our own content.

I guess (or hope) that seeding the key into the CPU in the first place is
what's going to make it hard for content owners to use for DRM?

