4 ms·

A fast, Cross-VM attack on AES [pdf]

28 points by timo_h 12y ago

edwintorok 12y ago
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 http://nacl.cr.yp.to/features.html
- 0x0 12y ago
  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!
  - sdevlin 12y ago
    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.
    - feld 12y ago
      Lack of a CA hierarchy sounds like a problem has just been solved for you
      - sdevlin 12y ago
        Yeah, it's arguably a plus.
  - edwintorok 12y ago
    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/ http://tweetnacl.cr.yp.to/ [2] http://doc.libsodium.org/ http://doc.libsodium.org/ [3] http://curvezmq.org/page:read-the-docs http://curvezmq.org/page:read-the-docs [4] http://curvecp.org/ http://curvecp.org/
feld 12y ago
Virtualization is not a security implementation. I've been saying this for years and I'll continue to keep my tinfoil hat on. As Theo DeRaadt said You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. 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.
- tptacek 12y ago
  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.
- jewel 12y ago
  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.
  - SixSigma 12y ago
    same webserver would have had users and groups - you have bought complexity instead of using the existing mechanisms
- jude- 12y ago
  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.

28 points by timo_h 12y ago

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 http://nacl.cr.yp.to/features.html

0x0 12y ago
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!
- sdevlin 12y ago
  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.
  - feld 12y ago
    Lack of a CA hierarchy sounds like a problem has just been solved for you
    - sdevlin 12y ago
      Yeah, it's arguably a plus.
- edwintorok 12y ago
  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/ http://tweetnacl.cr.yp.to/ [2] http://doc.libsodium.org/ http://doc.libsodium.org/ [3] http://curvezmq.org/page:read-the-docs http://curvezmq.org/page:read-the-docs [4] http://curvecp.org/ http://curvecp.org/

feld 12y ago

Virtualization is not a security implementation. I've been saying this for years and I'll continue to keep my tinfoil hat on. As Theo DeRaadt said You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. 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.

tptacek 12y ago
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.
jewel 12y ago
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.
- SixSigma 12y ago
  same webserver would have had users and groups - you have bought complexity instead of using the existing mechanisms
jude- 12y ago
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.