Prevent cold boot attacks using TRESOR | Hacker News Reader

Prevent cold boot attacks using TRESOR

www1.informatik.uni-erlangen.de

29 pointsthomas-st10 comments

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.

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.)

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.

For servers, a lot of these vectors go away, and if you're theoretically deploying 10k servers, you can spec the controllers, microcode, etc.

I gave up on PC desktops for security a long time ago; just use mobile, tablets, and things like ChromeOS for that. ARM with TrustZones should be enough to fairly easily build something.

What I'd really like is a physically tamper-responding tablet. i.e. the touchscreen, physical enclosure, and all ports sealed in an HSM-like enclosure, such that if you tamper with it, it zeroizes a platform security key, which can be used to remotely attest "I haven't been tampered yet" to servers before communicating. You would then do some kind of physical enclosure size/seals/standards to protect from skimmers layered outside the trusted device, and then some kind of device to user authentication to prove it's a valid device before entering information on it. You could pretty much build this on Android today.

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.

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).

I care about servers, not clients.

TRESOR plus TreVisor or an equivalent hypervisor is a necessary but not sufficient step to protecting a virtual machine from the physical server hardware or server operator. You also need trusted EFI (coreboot), Intel TXT, and a separation kernel (of which there are ~3 DOD funded ones, and a few more.

> as long as you trust a tiny subset of it -- potentially just the Intel CPU.

http://www.xakep.ru/post/58104/ (use Google Transalte)

TL;DR

The author has found an undeclared software module (backdoor?) working as a hypervisor in the System Management Block chip on the South Bridge working with Intel CPU with VT virtualization technology.

Yes -- it's pretty feasible for there to be lots of evil chips on a normal motherboard. It's not feasible for anyone but Intel to attack an E5 CPU right now, and probably not for the next ~2y, unless there's an implementation bug -- no one else can make a chip that dense and fast right now.

The BIOS is probably the lowest hanging fruit for an attacker now. Most trusted boot doesn't even really check the BIOS in any real way, it starts sometime after the BIOS.

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?

Reply on news.ycombinator.com