Is AES-NI supported in Enclave?

[shen_y_]

Hi,

     I'm testing openssl(1.0.1m) in enclave on linux os , which is published in the sgx sdk sample code for windows. I use AES-CBC-128 to encrypt  100M data and it costs  1164.769ms. It's almost the same as the time cost of aes-cbc encryption without using aes-ni in the normal application. The time cost of aes-cbc using aes-in is about 223.12ms.

     So, I doubt that aes-ni is not supported for openssl in enclave. Is that right? How to enable aes-ni support?

Thanks

Yu

[Surenthar_S_Intel]

Hi,

OpenSSL library first checks if the underlying hardware supports AES-NI via cpuid. If it detects that the hardware supports, it uses the hardware AES instructions for its cryptographic operations, otherwise it falls back to a software implementation. OpenSSL library executing inside the enclave fails to detect that our hardware has AES-NI support. Thus, it uses a slower AES routine which adds latency by consuming more CPU cycles. We suspect that the SDK has not rolled out support for executing cpuid instruction inside the enclave. We suspect that the SDK has not rolled out support for executing cpuid instruction inside the enclave, as was pointed out by recent public disclosures "A. Baumann, M. Peinado, and G. Hunt, “Shielding Applications from an Untrusted Cloud with Haven,” in OSDI 2014". 

Linux SDK itself does not use hardware AES-NI instructions for encryption-decryption. Instead it uses software implementation of AES routine, as was pointed out by recent public disclosures "L. M. JP Aumasson, “SGX Secure Enclaves in Practice: Security and
Crypto Review — Kudelski Security,” Black Hat USA, 2016".

-Surenthar

[shen_y_]

Selvaraj, Surenthar wrote:

Hi,

OpenSSL library first checks if the underlying hardware supports AES-NI via cpuid. If it detects that the hardware supports, it uses the hardware AES instructions for its cryptographic operations, otherwise it falls back to a software implementation. OpenSSL library executing inside the enclave fails to detect that our hardware has AES-NI support. Thus, it uses a slower AES routine which adds latency by consuming more CPU cycles. We suspect that the SDK has not rolled out support for executing cpuid instruction inside the enclave. We suspect that the SDK has not rolled out support for executing cpuid instruction inside the enclave, as was pointed out by recent public disclosures "A. Baumann, M. Peinado, and G. Hunt, “Shielding Applications from an Untrusted Cloud with Haven,” in OSDI 2014". 

Linux SDK itself does not use hardware AES-NI instructions for encryption-decryption. Instead it uses software implementation of AES routine, as was pointed out by recent public disclosures "L. M. JP Aumasson, “SGX Secure Enclaves in Practice: Security and
Crypto Review — Kudelski Security,” Black Hat USA, 2016".

-Surenthar

I've noticed "the AES implentation made available to Linux developers uses a slower AES implementation without native instructions, yet also with cache-timing mitigations." But why ? Why not use native instructions? Can I enable it by myself ? 

[Juan_d_Intel]

The open source version of the cryptographic primitives in the Intel(R) SGX SDK for Linux is a subset of the Intel(R) IPP Cryptography library and provided as reference implementation. It is written in pure C and is not optimized for performance. With the Linux 1.7 we provide an optimized IPP crypto library, which is posted in 01.org. By default, the Linux 1.7 SDK builds with this optimized library, which you will be asked to download first.

The OpenSSL code included in the Windows SDK was meant as sample code that shows how to do X.509 cert verification. After the Windows 1.7 SDK, we posted the SGXSSL Add-on that includes the sample code, which does depend on the optimized SGXSSL library. However, the SGXSSL library is not available on Linux.

[alc__ria]

Hi,

Does SGX SSL now automatically detect AES-NI hardware support for sgxssl version 2.0.x. I'm running SDK 2.0.4x on Linux.

-ria