Project

General

Profile

Feature #12301

Consider TreVisor for cold-boot and DMA resistance

Added by cypherpunks about 3 years ago. Updated almost 2 years ago.

Status:
Rejected
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
03/06/2017
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
No
Affected tool:

Description

TreVisor1 is a thin VMM based on BitVisor, with the TRESOR2 patches integrated. It is implemented as a GRUB2 module, transparently chainbooting any kernel (even Windows). It automatically encrypts devices with cold-boot resistant AES, and DMA-protects itself so that classical DMA attacks cannot hijack the hypervisor, eliminating issues such as TRESOR-HUNT3 entirely. In fact, any DMA attack which relies on getting bus master is defeated, such as PCI/PCIe hotplugging, hijacking an existing device with bus master (such as the NIC), asserting LDRQ# on the LPC bus, etc. While there are software mitigations that would allow TRESOR to work, they rely on enabling DMAR on the host with intel_iommu=on, which was shot down in #11886#note-7 due to issues with some hardware. TreVisor does not have those issues because it does not rely on potentially buggy DMAR tables provided by the BIOS. It DMA-protects itself, so it will work as long as the system has a functioning IOMMU. Note that it only protects itself, not the rest of the system. In other words, an attacker can still do whatever they want to ring >= 0, but they cannot touch ring -1 where the encryption key and TreVisor code resides.

For TreVisor to work, a system must have VT-d, VT-x, and AES-NI. A simple patch should allow it to work without AES-NI, but VT-d and VT-x are necessary. However, if they are not present, TreVisor could be made to automatically chainboot the Tails kernel, keeping itself out of the picture from then on. The only other issue is that it, by default, requires manually setting the key while installing it, before first boot, and from then on it will transparently use AES with all drives, so unencrypted drives or drives not encrypted with the password entered would be unreadable. I don't think that would be hard to fix, though. It should not be difficult to have the encryption key set through the Tails Persistent Volume GUI, and locked to an individual partition UUID.

Since this would solve both DMA issues (which are a horribly common reality) without relying on the OEM's DMAR tables, and cold boot attacks, I hope integrating this project can be considered. As it is not an application which needs to be installed in Debian and interacts with Debian, it is not something which belongs upstream, and is fundamentally separate. I would not be able to go to Debian to get them to take it in.

[1] https://www1.cs.fau.de/filepool/projects/trevisor/trevisor.pdf
[2] http://www1.informatik.uni-erlangen.de/filepool/projects/tresor/tresor.pdf
[3] https://seclab.ccs.neu.edu/static/publications/acsac2012dma.pdf

History

#1 Updated by Anonymous almost 3 years ago

  • Assignee set to intrigeri
  • Type of work changed from Code to Discuss

From what I understand, TRESOR is a kernel patch which secures an unencrypted boot partition. It implements AES but keeps the master-key not in RAM but in CPU registers during runtime. I don't think it's in Tails that this should be done, but in the Debian kernel.

Trevisor seems to be a continued development of this, but here again, even if this is not a software to be installed, something like this should be proposed to Debian directly.

Assigning to foundations team to approve/comment/reject my comment and eventually rejecting or further investigating this ticket.

#2 Updated by Anonymous almost 3 years ago

  • QA Check set to Info Needed

#3 Updated by Anonymous almost 3 years ago

  • Priority changed from Normal to Low

#4 Updated by intrigeri almost 3 years ago

  • Assignee changed from intrigeri to cypherpunks
  • Type of work changed from Discuss to Research

It seems that lots of upstream improvements would be needed before we can use that (at least the bits about VT-d/VT-x and supporting unencrypted drives). Assuming these upstream issues are addressed by someone (who?) and the software is then packaged in Debian (I see no reason why we would package/build this differently), then we would need to 1. define a user story for the whole thing (e.g. would this be about the persistent volume only? the system partition too? when does the user type the encryption passphrase, and in which interface?); 2. fully switch to GRUB2.

So this is a large project. We don't have the resources to tackle it at this point, and IMO we have a number of other large projects with much higher priority. So my question is: do you personally intent to put whatever time+energy is needed to make this happen? Otherwise let's close this ticket to avoid turning our Redmine into a Christmas shopping list :)

#5 Updated by tailshark almost 3 years ago

I've been looking very closely at remastering official Tails ISOs with a Tresor-style kernel patch for over a year now. This thread interested me because of how close to my goals it hits... and I didn't want to create a new thread since I don't see a section dedicated to "Christmas wishlist". :)

My approach would be different from the author's though. Rather than depending on IOMMU or a chainloading mechanism (though I agree chainloading would be more modular) I'm personally going straight for kernel patches for my remastering. The idea is to encrypt userland (non-kernel) memory ---AND--- to patch the kernel's primary crypto system to RE-ENCRYPT the hard disk keys floating in kernel memory with the TRESOR CPU keys. In other words, even if something is able to dump ring0's dedicated memory (in ram) those disk keys are still useless on their own. This would allow existing disk keys to work as-is without needing to change or reencrypt any drives, without needing to map/remember UUIDs, etc... In the case of the standard (classic) Tresor patch it only tweaks the area of the kernel that goes to access pages of userland memory and reencrypts (in place) ones it's leaving while decrypting (in place) ones it's entering. So the classic patch isn't a colossal change but there are no existing hooks for something nicer (like a kernel module) to insert itself into that area of the kernel code.

The problem here is that, as far as Tails integration goes, it completely violates their NIH (not invented here) policy once someone embarks on kernel modifications that are not part of upstream. So I've been keeping my mouth shut and working on it as a private project. I am totally open to sharing the work with the Tails community once I get it into shape and will be actively maintaining the work for my own personal usage ...BUT... I don't know that I'm completely motivated to try to navigate the politics of the kernel/Debian upstream.

I put this out here as a feeler primarily. If interested in the work let me know and I'll publish my remastering once it's ready.

#6 Updated by intrigeri almost 3 years ago

The problem here is that, as far as Tails integration goes, it completely violates their NIH (not invented here) policy once someone embarks on kernel modifications that are not part of upstream. So I've been keeping my mouth shut and working on it as a private project. I am totally open to sharing the work with the Tails community once I get it into shape and will be actively maintaining the work for my own personal usage ...BUT... I don't know that I'm completely motivated to try to navigate the politics of the kernel/Debian upstream.

Is the TRESOR project interested in having their patch in mainline Linux and make a real difference, or is it a research / PoC project that satisfies itself with an tiny userbase of enthusiasts users who build their own custom kernel (which could make sense during the initial phase of a project, even though TRESOR is not exactly a young project)? Has there been any attempt at upstreaming their code yet?

#7 Updated by mercedes508 over 2 years ago

  • Assignee changed from cypherpunks to tailshark

#8 Updated by mercedes508 over 2 years ago

ping?

#9 Updated by mercedes508 about 2 years ago

  • Status changed from New to Rejected

closing it as none of the interested ones answered back since 7 months.

#10 Updated by cypherpunks almost 2 years ago

intrigeri wrote:

So this is a large project. We don't have the resources to tackle it at this point, and IMO we have a number of other large projects with much higher priority. So my question is: do you personally intent to put whatever time+energy is needed to make this happen? Otherwise let's close this ticket to avoid turning our Redmine into a Christmas shopping list :)

Yes, it is a large project. I have already done this for a test system of my own, but I doubt it would be acceptable by the Tails project as-is (it does not support external unencrypted drives, for example).

tailshark wrote:

My approach would be different from the author's though. Rather than depending on IOMMU or a chainloading mechanism (though I agree chainloading would be more modular) I'm personally going straight for kernel patches for my remastering. The idea is to encrypt userland (non-kernel) memory ---AND--- to patch the kernel's primary crypto system to RE-ENCRYPT the hard disk keys floating in kernel memory with the TRESOR CPU keys. In other words, even if something is able to dump ring0's dedicated memory (in ram) those disk keys are still useless on their own. This would allow existing disk keys to work as-is without needing to change or reencrypt any drives, without needing to map/remember UUIDs, etc... In the case of the standard (classic) Tresor patch it only tweaks the area of the kernel that goes to access pages of userland memory and reencrypts (in place) ones it's leaving while decrypting (in place) ones it's entering. So the classic patch isn't a colossal change but there are no existing hooks for something nicer (like a kernel module) to insert itself into that area of the kernel code.

I've done something similar to this as well. It does not encrypt memory because that is... very, very slow. Really, absurdly slow (tests showed it take between 15 minutes and an hour to boot an equivalent Debian Live system in a virtual machine, compared to 30 to 45 seconds without the modifications with KVM and 5 minutes without). This is nice in theory, but really not very practical. It may be possible to encrypt individual processes with a little less overhead, though, in the way RamCrypt does. The Tor process would be an ideal target.

intrigeri wrote:

Is the TRESOR project interested in having their patch in mainline Linux and make a real difference, or is it a research / PoC project that satisfies itself with an tiny userbase of enthusiasts users who build their own custom kernel (which could make sense during the initial phase of a project, even though TRESOR is not exactly a young project)? Has there been any attempt at upstreaming their code yet?

No they are not. There is absolutely no way TRESOR or anything even vaguely related would ever be accepted upstream. In fact, several of the core kernel developers are viscerally opposed to it. It was designed for research purposes, and as such still has a few issues (registers containing key material are pushed to memory during NMIs and SMIs. I modified the patch to account for that and a few other things on my local system). Doing that would be quite easy though, as the patches are actually really simple when you look at it. TreVisor would not be so easy though, but TRESOR would be.

mercedes508 wrote:

closing it as none of the interested ones answered back since 7 months.

I'm back. While I don't think TreVisor would be accepted into Tails due to requiring substantial in-house development, TRESOR seems to be a significantly more-practical alternative, albeit with a simpler threat model.

#11 Updated by cypherpunks almost 2 years ago

Should I open a new ticket for TRESOR integration, since it seems pretty clear to me now that integrating TreVisor is a quixotic endeavor? I could maintain a kernel module compatible with the Debian kernel which does that myself, along with various (non-intrusive) improvements to TRESOR which make it more production-safe, but it would be necessary for it to be separate from upstream, since Debian is unlikely to take it and the Linux Foundation, even less.

The reason I've been gone so long is because, ever since grsecurity went private and Tails showed absolutely no interest in purchasing support from them (KSPP is a joke, don't start that), I've sort of given up on improving the security of Tails. When your hard drive has several kernel-busting bugs lying around that only work on the Debian kernel because of how badly designed it is, you begin to lose motivation. I have considered developing my own commercial fork of Tails, but would need to look into that more before I begin.

Also available in: Atom PDF