This article introduces enabling Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI) on Android, focusing on what it is, how to use it, and how to measure performance. We’ve also included a usage model and examples in combination with two cryptograph scenarios that show how Intel AES-NI instructions can be used. Senior developers may choose to skip the first four sections of this article and go directly to the last one to review the usage scenarios. Less experienced developers will probably want to read all of the sections.
Intel Advanced Encryption Standard New Instructions (Intel AES-NI)
Checking for Intel AES-NI Support on Android
Using Intel AES-NI on Android
Use the Assembly Library
The Author-created Tool’s Test Results
Intel AES-NI Usage Scenarios
Intel AES-NI was proposed in March, 2008 and is an extension of the x86 instruction set architecture for Intel and AMD microprocessors. The purpose of the instruction set is to improve the speed of applications performing encryption and decryption using the Advanced Encryption Standard (AES).
The Intel AES-NI instructions are listed in Table 1.
Table 1: Intel® AES-NI Instructions
|AESENC||Perform one round of an AES encryption flow|
|AESENCLAST||Perform the last round of an AES encryption flow|
|AESDEC||Perform one round of an AES decryption flow|
|AESDECLAST||Perform the last round of an AES decryption flow|
|AESKEYGENASSIST||Assist in AES round key generation|
|AESIMC||Assist in AES Inverse Mix Columns|
To check whether Intel AES-NI is supported on a platform, you can get the information from the CPUID; check that CPUID.01H:ECX.AESNI[bit 25] = 1. You can also use the check_for_aes_instructions function in the Intel AES-NI sample library.
There are several ways to use Intel AES-NI on Android:
- Write C/C++ code and use assembly code directly
- Use an existing third-party library like OpenSSL*
- Use Java* Crypto API from Android Kitkat
To compile a native library/application for x86 on Android, you need to make a standalone tool chain using the make-standalone-toolchain.sh command provided by the Android NDK:
$NDK_PATH/build/tools/make-standalone-toolchain.sh –install-dir=$STANDALONE_TOOCHAIN_PATH –toolchain=x86-4.8 –platform=android-14 –ndk-dir=$NDK_PATH export PATH=$PATH:$STANDALONE_TOOCHAIN_PATH
The library can be found in the intel_aes_lib directory or you can access it from http://software.intel.com/en-us/articles/download-the-intel-aesni-sample-library. Be sure to use GCC version 4.4 or later, which means the NDK version should be newer than NDK v3. (For our purposes here, we are using android-ndk-r9 for testing.)
There is no makefile/shell script for building Android versions. You can change the mk_lnx86.sh to compile it. The main change is to use $STANDALONE_TOOCHAIN_PATH/bin/i686-linux-android-gcc to replace the default GCC and pass –D__ANDROID__ as parameters.
export CC=”$STANDALONE_TOOLCHAIN_PATH/bin/i686-linux-android-gcc –D__ANDROID__ --sysroot=$STANDALONE_TOOLCHAIN_PATH/sysroot -I$STANDALONE_TOOLCHAIN_PATH/sysroot/include”
After compiling, you can push the binary executive program them to the Android system and test it. You can also use the source code directly in your own applications or use the created binary library in the following NDK way.
There are many libraries that use Intel AES-NI, such as crypto++ polar SSL IPP OpenSSL and others. (For our purposes, we are using OpenSSL as a reference ‒ OpenSSL-supported Intel AES-NI from the v1.0 experimental version).
The good news is that beginning with Android 4.3, OpenSSL in AOSP has supported Intel AES-NI, so you just need to compile it with the correct configuration. Also, you can download it from the official website and compile it yourself, then use the *.a/*.so in your project directly.
(1) Download ‒ You can download OpenSSL from http://www.openssl.org/source/. Currently, Android 4.2 uses openssl-1.0.1c and Android 4.4 uses openssl-1.0.1e, so you should use the same version as the OpenSSL used in the system you target.
(2) Compile ‒ Run the following command on your console:
cd $OPENSSL_SRC_PATH export CC=”$STANDALONE_TOOCHAIN_PATH/bin/i686-linux-android-gcc –mtune=atome –march=atom –sysroot=$STANDALONE_TOOCHAIN_PATH/sysroot” export AR=$STANDALONE_TOOCHAIN_PATH/bin/i686-linux-android-ar export RANLIB=$STANDALONE_TOOCHAIN_PATH/bin/i686-linux-android-ranlib ./Configure android-x86 –DOPENSSL_IA32_SSE2 –DAES_ASM –DVPAES_ASM make
Then you can get libcrypto.a in the top directory. If you want to use *.so file, enter “Configure shared android-x86 ***”.
(3) Use OpenSSL via the NDK in Android Project ‒ Create an android project, declare the OPENSSL-related function as native function, and then implement in the jni/*.c.
After doing that, you need to copy the *.a/*.so and header file into the project.
mkdir jni/pre-compiled/ mkdir jni/include cp $OPENSSL_PATH/libcrypto.a jni/pre-compiled cp –L -rf $OPENSSL_PATH/include/openssl jni/include
Then add the following line into the jni/Android.mk file:
… LOCAL_MODULE := static LOCAL_SRC_FILES := pre-compiled/libcrypto.a … LOCAL_C_INCLUDES := include LOCAL_STATIC_LIBRARIES := static –lcrypto …
Then, you can use functions provided by OpenSSL to implement your encrypt/decrypt/SSL functions. To use Intel AES-NI, just use the EVP_* series function as shown below, which will automatically use Intel AES-NI to accelerate AES encryption/decryption if the CPU supports it.
//declare EVP_CIPHER_CTX en, de; //init EVP_CIPHER_CTX_init(&en); EVP_CIPHER_CTX_init(&de); EVP_DecryptInit_ex(&de, NULL, NULL, NULL, NULL); //decrypt & encrpyt EVP_DecryptUpdate(&de, plaintext, &bytes_written, ciphertext, len); EVP_EncryptUpdate(&en, ciphertext, &cipher_len, plaintext, len); //clean up EVP_CIPHER_CTX_cleanup(&en); EVP_CIPHER_CTX_cleanup(&de);
Then use ndk-build to compile.
(4) Use Java Crypto API ‒ From Android Kitkat, the OpenSSL provider named “AndroidOpenSSL” has supported Intel AES-NI, and you can use javax.crypto.Cipher directly.
Cipher cipher = Cipher.getInstance(AES_ALGORITHM, “AndroidOpenSSL”); cipher.init(*);
You can use the following four methods to test and record performance:
(1) Use the OPENSSL tool. OpenSSL’s openssl command can do many tasks. It can be used to measure performance via openssl speed. By default, openssl (which builds with an AES_ASM option) will automatically use Intel AES-NI HW acceleration. It also provides a simple way to disable HW acceleration via setting one environment variable: OPENSSL_ia32cap to ~0x200000200000000
openssl speed –evp aes-256-cbc OPENSSL_ia32cap=~0x200000200000000 openssl speed –evp aes-256-cbc
(2) Use the self-created tool.
Figure 1: Test Tool We Created
(3) The Intel® Mobile Platform Monitor (Intel® MPM) is a power monitoring tool to profile and get detailed information about CPU/GPU/POWER, etc. For more information, go to http://software.intel.com/en-us/articles/intel-power-monitoring-tool-for-android-devices-a-power-and-performance-related-data
Figure 2: Intel® MPM Tool
Intel MPM’s usage is very simple. Just start profiling and then run your target applications or entire system. After your job is finished running or your application has run long enough, open Intel MPM again and press stop profiling, then save the resulting data. The results may be displayed as either a text summary or a graphic.
(4) Use a test application from the Intel AES-NI library at http://software.intel.com/en-us/articles/download-the-intel-aesni-sample-library. You can use enable/disable AESNI in BIOS in some test projects such as aes_gladman_subset to show performance results.
We [say what software you ran] on a Bay Trail tablet running Android 4.4. Our test results show a 4x-11x performance improvement for encryption/decryption and save 40%+ battery power using Intel AES-NI.
Detailed test information shows the following:
openssl speed result. The screen shot below depicts running openssl to test speed.
Figure 3: Result of openssl Command
Table 2: Test Results via a Author-Created Tool
|HW: BAYTRAIL_FFRD8 PR1, OS: ANDROID 4.4|
|File Size||Intel® AES-NI Enabled||Intel AES-NI Disabled|
|T(s) w/o I/O||T(s) w/ I/O||T(s) w/o I/O||T(s) w/ I/O|
Without I/O from the table above
Encrypt: nearly 5x performance improvement, similar to the result using OPENSSL
Decrypt: nearly 11x performance improvement
With I/O from the table above
Encrypt: nearly 1.9x performance improvement
Decrypt: nearly 2x performance improvement
Intel MPM Tool Test Result
We used our tool as the target application for testing, with the following results:
Figure 4: Test Results for AESNI_DISABLED W/ I/O (16s total)
Figure 5: Rest results for AESNI_ENABLED W/ I/O (30s total)
Summarizing the Intel MPM’s test results:
AESNI_ENABLED: battery power used 20 mWh; CPU average usage 55% AESNI_DISABLED: battery power used 34 mWh; CPU average usage 52%
NOTE: By enabling Intel AES-NI, ~40% battery power can be saved in comparison with software solution.
An AES algorithm is widely used in data-safe scenarios such as network data transmission cryptograph, full disk, or file cryptograph, Intel AES-NI can be used in all of these scenarios while the CPU support it. Figure 6 shows typical network data transmission, with all data transferred and encrypted between users and servers after authentication is passed.
Figure 6: Typical Network Data Transmission
Another typical case is full disk or file encryption, when users must save data in local storage. Figure 7 shows the entire work flow from user to storage:
Figure 7: Entire Encryption Work Flow
Intel AES-NI hardware instructions support both high performance and power efficiency, benefits that are extremely important for mobile devices such as smartphones and tablets. Mobile device management (MDM) and mobile content management (MCM) are very important considerations in an enterprise security solution. This section focuses on Intel AES-NI in combination with MDM and MCM.
One example of MDM is when administrators send messages or commands to end users, and these sensitive transmissions must be encrypted. The software solution offered by AES easily drains battery power during frequent communication, but the Intel AES-NI solution uses hardware instructions that save power and improve performance. Figure 8 shows a typical scenario of administrators sending commands to users with an Intel AES-NI-based cryptograph solution. The workflow includes encrypting commands before they are sent and decrypting data to execute the commands on end-user devices.
Figure 8: MDM communications utilizing the AES cryptograph
An example of MCM is when users access highly confidential data such as documents, pictures, videos, etc. from enterprise servers. Such transmissions must be strictly protected. All data must be encrypted before sending to end users and must retain the encrypted formats when stored on end-user devices. Figure 9 shows a typical MCM workflow from beginning to end when read and stored by the end user. Intel AES-NI instructions support a 256-bit cryptograph algorithm, so it is an excellent hardware solution for enterprise security and confidentiality requirements.
Figure 9: MCM Workflow
To employ Intel AES-NI hardware acceleration, developers need to use NDK programming. Figure 10 shows the typical layer relationships for Android applications, the Android cryptograph module, and the Intel AES-NI C/C++ module. Java Native Interface (JNI) is used to link C/C++ functions to Java functions. If you are not familiar with NDK programming, please see the reference on NDKs for more information.
Figure 10: Typical Layer Relationships
This article introduces how to use Intel AES-NI instructions to accelerate cryptography on Android devices. It shows how developers can use ASM codes, 3rd-party libs, and Intel NDK to speed up applications and save power as well. Two typical scenarios of encrypting/decrypting data were described to help developers use Intel AES-NI in their applications.
Android developers can learn more about Intel® tools by visiting: Intel® Developer Zone for Android.
Zhang Li is an application engineer in the Intel® Software and Solutions Group (SSG), Developer Relations Division, Mobile Enterprise Enabling team. He focuses on application enabling on Android.
Yanqing Wang is an application engineer in the Intel Software and Solutions Group (SSG), Developer Relations Division, Mobile Enterprise Enabling team. He focuses on the security and manageability of enterprise. He is an Intel® Developer Zone (IDZ ) Black Belt.
Intel, the Intel logo, Atom, Celeron, Core, Pentium, and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries.
*Other names and brands may be claimed as the property of others.
Copyright ©2014 Intel Corporation. All rights reserved.