A fast, Cross-VM attack on AES [pdf](eprint.iacr.org)
eprint.iacr.org
A fast, Cross-VM attack on AES [pdf]
http://eprint.iacr.org/2014/435.pdf
2 comments
That ship has already sailed, so much so that real companies are willing to execute hostile code inside Docker instances; Docker isn't even virtualized.
Given that virtualization is the de facto standard deployment technology for the majority of all new applications, it's worth knowing the specific limitations.
Given that virtualization is the de facto standard deployment technology for the majority of all new applications, it's worth knowing the specific limitations.
Virtualization does offer additional security if it's used to isolate things that otherwise would have been running on the same host. For example, at my old job we used OpenVZ to isolate wordpress, twiki, and roundcube, whereas historically we would have had them all installed on the same webserver.
I think this is the original source of the confusion, which has since disseminated to those who don't understand the nuances and think that virtualization adds security in every case.
The PCI DSS requires that each server just has one purpose. I was surprised when in a later version they explicitly allowed virtualization as a way to comply with that requirement.
I think this is the original source of the confusion, which has since disseminated to those who don't understand the nuances and think that virtualization adds security in every case.
The PCI DSS requires that each server just has one purpose. I was surprised when in a later version they explicitly allowed virtualization as a way to comply with that requirement.
same webserver would have had users and groups - you have bought complexity instead of using the existing mechanisms
While I agree with Theo in principle, it sounds like he's precluding the possibility that one can create a virtualization layer with formally-proven correctness guarantees (be it a hypervisor, an OS, or an application VM). For example, seL4 is proven to be free of many common types of bugs (NULL pointer dereferences, use-after-free errors, buffer overflows, etc.) that lead to security holes. AFAIK, there is no such proof for OpenBSD.
I'm not trying to suggest that a virtualization layer with formal proofs of correctness is a security panacea (it's not--correctness is necessary but not sufficient for security). What I am suggesting is that there is a way forward to developing secure virtualization layers.
If anything, this paper suggests to me that it would be best if the lowest layer in the stack (be it the OS or the hypervisor) implemented some of the crypto primitives on behalf of the applications. I can't see any other way to run them while also guaranteeing that (1) their execution is correct with the specification, (2) they run in full isolation from one another, and (3) they avoid timing attacks and whatever side-channels we can think of.
I'm not trying to suggest that a virtualization layer with formal proofs of correctness is a security panacea (it's not--correctness is necessary but not sufficient for security). What I am suggesting is that there is a way forward to developing secure virtualization layers.
If anything, this paper suggests to me that it would be best if the lowest layer in the stack (be it the OS or the hypervisor) implemented some of the crypto primitives on behalf of the applications. I can't see any other way to run them while also guaranteeing that (1) their execution is correct with the specification, (2) they run in full isolation from one another, and (3) they avoid timing attacks and whatever side-channels we can think of.
The paper only talks about T-table AES implementation,
but it should probably mention at countermeasures this paper "Faster and timing-attack resistant AES-GCM" by Emilia Käsper and Peter Schwabe at CHES 2009, which I found when looking at 'No data-dependent array indices' feature of NaCl:
http://nacl.cr.yp.to/features.html
I'm curious about NaCl, would it be possible to replace OpenSSL with something based on this library? If not, why not?
The feature list certainly looks impressive!
The feature list certainly looks impressive!
It depends on your use case.
If you need something that speaks TLS, then no. NaCl is a different (simpler) protocol that does not have TLS compatibility as a goal.
If you're building a new application then NaCl is probably a good choice. There are some problems you may need to solve yourself, if your application calls for them. For example, NaCl has no notion of a CA hierarchy.
If you need something that speaks TLS, then no. NaCl is a different (simpler) protocol that does not have TLS compatibility as a goal.
If you're building a new application then NaCl is probably a good choice. There are some problems you may need to solve yourself, if your application calls for them. For example, NaCl has no notion of a CA hierarchy.
If you have to interoperate with something already using OpenSSL then probably not.
If you are writing a new application then read on.
There are 2 NaCl alternatives to consider as well: Sodium (API compatible) [2], TweetNaCl (small, auditable) [1].
There are higher-level protocols that uses NaCl, CurveCP [3] for UDP, and CurveZMQ for TCP[4], although "CurveCP software isn't ready for users yet".
[1] http://tweetnacl.cr.yp.to/ [2] http://doc.libsodium.org/
[3] http://curvezmq.org/page:read-the-docs [4] http://curvecp.org/
If you are writing a new application then read on.
There are 2 NaCl alternatives to consider as well: Sodium (API compatible) [2], TweetNaCl (small, auditable) [1].
There are higher-level protocols that uses NaCl, CurveCP [3] for UDP, and CurveZMQ for TCP[4], although "CurveCP software isn't ready for users yet".
[1] http://tweetnacl.cr.yp.to/ [2] http://doc.libsodium.org/
[3] http://curvezmq.org/page:read-the-docs [4] http://curvecp.org/
As Theo DeRaadt said
I caught someone in a meeting last week trying to sell another employee on the security benefits of virtualization and I nearly bit my tongue off.