2. For God's sake don't use XTS for anything other than FDE.
There's an encrypted filesystem guy that suggested they were moving to XTS. That's what prompted the post.
Usability is great. I think you should turn FDE on. But turning on FDE buys you a lot less than you think it does. There's a pretty good chance that FDE isn't going to do anything for you if your computer is seized by the FBI, because the key will probably resident when they do that.
You don't want XTS, in general, because you don't want to turn a simpler problem (safely encrypting your secrets) into a hard problem (simulating hardware encryption).
Do you know if there are any effective forensic attacks in use against the TRESOR design?
(I was one of the authors of the cold boot paper at USENIX Security, but I haven't followed the subsequent history of attacks and defenses very consistently.)
I remember the DMA situation from a few years ago being quite bad, and it looks like you or one of your colleagues has posted some good resources on that at
I realize that with PrivateCore you're taking quite a comprehensive approach to this problem and not bothering with more piecemeal counterforensic approaches, but I'm still curious about what counterforensic techniques exist for people who aren't going as far as you are. For example, can we make stock Linux deny memory access on external buses with a software policy, or is this simply not something that can be accomplished from software?
I imagine you have good arguments for why the piecemeal approach is likely to fail in the face of an skilled forensic attacker. But many of the attacks that you described to me when we last talked about this were more along the lines of hardware-assisted Evil Maid attacks in an unmonitored and unsupervised colo, rather than forensic attacks against an unmodified encrypted laptop. I'm curious about how different the threat scenarios are between these two cases now.
Enabling IOMMU is one relatively easy software mitigation to DMA attacks. There are some gaps, but it stops the trivial cases where a device can access all of memory.
In practice, many encrypted filesystems already use encryption that's strictly worse than XTS, and they generally use the same block-based model as full disk encryption for exactly the same performance reasons.
Comments
The post ends with the takeaways I'm hoping for:
1. Try not to rely on FDE at all.
2. For God's sake don't use XTS for anything other than FDE.
There's an encrypted filesystem guy that suggested they were moving to XTS. That's what prompted the post.
Usability is great. I think you should turn FDE on. But turning on FDE buys you a lot less than you think it does. There's a pretty good chance that FDE isn't going to do anything for you if your computer is seized by the FBI, because the key will probably resident when they do that.
You don't want XTS, in general, because you don't want to turn a simpler problem (safely encrypting your secrets) into a hard problem (simulating hardware encryption).
Do you know if there are any effective forensic attacks in use against the TRESOR design?
(I was one of the authors of the cold boot paper at USENIX Security, but I haven't followed the subsequent history of attacks and defenses very consistently.)
TRESOR is only effective against passive forensics and only protects key material.
It does not protect against an attacker able to manipulate memory contents through, say, DMA or other malicious devices.
Hi Steve,
I remember the DMA situation from a few years ago being quite bad, and it looks like you or one of your colleagues has posted some good resources on that at
http://privatecore.com/resources-overview/physical-memory-at...
I realize that with PrivateCore you're taking quite a comprehensive approach to this problem and not bothering with more piecemeal counterforensic approaches, but I'm still curious about what counterforensic techniques exist for people who aren't going as far as you are. For example, can we make stock Linux deny memory access on external buses with a software policy, or is this simply not something that can be accomplished from software?
I imagine you have good arguments for why the piecemeal approach is likely to fail in the face of an skilled forensic attacker. But many of the attacks that you described to me when we last talked about this were more along the lines of hardware-assisted Evil Maid attacks in an unmonitored and unsupervised colo, rather than forensic attacks against an unmodified encrypted laptop. I'm curious about how different the threat scenarios are between these two cases now.
Enabling IOMMU is one relatively easy software mitigation to DMA attacks. There are some gaps, but it stops the trivial cases where a device can access all of memory.
Do you happen to have a link where I can read more about those?
In practice, many encrypted filesystems already use encryption that's strictly worse than XTS, and they generally use the same block-based model as full disk encryption for exactly the same performance reasons.
Okay, so I seem to have gotten the gist of it.
Still, I want XTS. :-)
If I was hoping to persuade someone other than a potential crypto designer, I probably wouldn't have tried to explain the XEX tweak. :)
Every developer is a potential crypto designer. Alas, quite a few of them turn out to actually design crypto. Not everyone is reading HN. ;-)