Security is a very important aspect of our everyday life. Internet expansion into most human existence reveals the need for additional security for both existing and future applications. Though crypto code solves a lot of security issues it can also introduce noticeable and sometimes far too much overhead on an application‘s performance.
One solution for this problem can be to use the AES (Advanced Encryption Standard) crypto accelerators. AES is an encryption standard adopted by the U.S. government starting in 2001. It is widely used across the software ecosystem to protect network traffic, personal data, and corporate IT infrastructure. AES is a symmetric block cipher that encrypts/decrypts data through several rounds. A set of new AES instructions were included with the Intel Architecture starting with the 2010 Intel® Core™ processor family, These instructions are referred to as the Intel® Advanced Encryption Standard (AES) New Instructions (AES-NI) +. The instructions were designed to implement some of the complex and performance intensive steps of the AES algorithm using hardware and thus accelerating the execution of the AES algorithms. Depending on the workload, Intel AES-NI can be used to accelerate the performance of an implementation of AES by anywhere from 3 to 10x over a completely software implementation. For more details about Intel AES-NI, please see the following article: “Intel® Advanced Encryption Standard Instructions (AES-NI)”
It is no wonder that “Intel AES-NI technology“ is always in the top 10 searches that Intel customers are looking for according to software.intel.com site metrics. This article will address Intel AES-NI usage in Java* on Linux*.
Java* is one of the most popular platforms in the server market. It includes Security APIs with a Java* Crypto Architecture framework which contains standard cryptographic services and implementations offered by many Crypto Providers. This allows for end users to use standard APIs with their choice of Crypto Providers without changing user code. All that is required is a bit of configuration of the JDK. We have heard a lot of questions asking how to benefit from implementing Intel AES-NI in Java* on Linux*; here is a recipe.
NSS¹ is an open source cryptographic library used in a number of products and is available under MPL, GPL and LGPL licenses. Although NSS* has Intel AES-NI support starting with version 3.12.5, we suggest using NSS* version 3.12.9 or newer. The NSS* library is plugged into the JDK
via Java™ PKCS#11 Crypto Provider with a small amount of JDK configuration. Java™ PKCS#11² is a standard interface and is a topic for a separate article.
This article provides a methodology for setting up the required environment followed examples of performance benefits that can be seen from implementing Intel AES-NI.
Here is a simple BKM on how to configure the JDK to use NSS* crypto library with 5 simple steps; the same BKM should be valid for Java* 6, 7, and 8.
|Step 1: Download NSS and Configure the JDK to use the NSS Crypto provider|
|Download NSS||URL: http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_10_RTM/src/nss-3.12.10-with-nspr-4.8.8.tar.gz Note: this is not the latest version of NSS, you can get a newer version at Mozilla’s ftp.|
|Step 2: Update JRE Security Providers|
|Step 3: Put nss.cfg into JDKX/jre/lib/security|
|Copy nss.cfg||Put nss.cfg in the following folder: JDKX/jre/lib/security |
Example of nss.cfg:
|* $NSS_LIBS_PATH - is full path to folder with NSS binaries as mentioned in NSS usage instructions|
|Step 4: Run your Java Application|
|Run||Run your Java application using the JDK you prepared|
|Step 5: Troubleshooting|
If the application uses unpadded data blocks for encoding there can be issues like CRK_DATA_LEN_RANGE exception.
This can be fixed by formally specifying the padding scheme via the Cipher class as shown in the following example:
The simple BKM proposed above enables Intel AES-NI support in Java on Linux* x64. This BKM is also covered in the p11guide.html³ on the Oracle* website. This guide also provides more configuration parameters. The NSS* crypto library can provide additional performance benefits when used with Oracle JDK* due to highly optimized software implementation of certain crypto algorithms. Intel AES-NI support is triggered automatically if NSS* runs on hardware supporting Intel AES-NI.
Now let’s look at the performance benefits of Intel AES-NI usage by examining the “Standard benchmark”, the “Micro benchmark, and the actual user experience.
There is a well-known benchmark which partly reflects cryptographic performance on Java. This is the crypto workload from the SPECjvm2008** benchmark. It consists of 3 different parts: crypto.aes, crypto.rsa and crypto.signverify. The part we are interested in is crypto.aes. The measurements below show that the crypto.aes benchmark from SPECjvm2008** results in about a 20% performance increase when Intel AES-NI is used on a system with Intel® Xeon® 7500 series CPU onboard under Red Hat* Enterprise Linux Server 5.5. The performance increase may vary according to OEM system configuration. Note that comparison was done between 2 runs both with the NSS crypto provider, but in the first case Intel AES-NI was used and in the second case Intel AES-NI was disabled. One can ask why there is such a small performance improvement as there were a lot of articles about greater performance gain with Intel AES-NI technology. The answer is simple; this is due to specifics of the crypto.aes workload which performs encoding and decoding using two algorithms: AES and 3DES. While making AES faster with Intel AES-NI technology DES3 effect on final score increases and therefore according to Amdahl’s law we see lower impact on crypto.aes score.
This benchmark was specifically targeted to stress the AES crypto code. The benchmark consistently encrypts and decrypts portions of data in one thread using the AES algorithm. The ratios provided are just for demonstration of Intel AES-NI performance enhancement degree and highly dependent on micro benchmark implementation, chosen crypto algorithms and key
|Data block||Intel AES-NI on / Intel AES-NI off (128-AES-CBC) encrypt|
|Data block||Intel AES-NI on / Intel AES-NI off (128-AES-CBC) decrypt|
Additionally here is link to a blog http://blog.fuseyism.com/index.php/category/performance/ with NSS* testing results using OpenJDK* (IcedTea).
Real User Experience
One example is the following case study about Intel AES-NI testing results on Java in the HealthCare sector: http://premierit.intel.com/docs/DOC-6471. The testing discussed in this article indicates a performance improvement of up to 38% on their application.
Developers start thinking about optimization of Crypto performance when their crypto code starts consuming noticeable amount of CPU resources. It is clear that performance gains due to Intel AES-NI use can be significant. Java* simplifies Intel AES-NI integration due to having JCA architecture which allows the use of Intel AES-NI without changing user code requiring just a small amount of JDK configuration. Additionally, NSS has a FIPS4 compliant mode which forces the use of certified crypto algorithms making the NSS library to be a very powerful tool in appropriate hands.
|AES||Advanced Encryption Standard|
|AES-NI||AES New Instructions|
|JDK||Java Development Kit|
|IDE||Integrated Development Environment|
|BKM M||Best Known Method|
Copyright © 2012 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others
** SPEC and the benchmark name SPECjvm are trademarks of the Standard Performance Evaluation Corporation
+Intel® AES-NI requires a computer system with an AES-NI enabled processor, as well as non-Intel software to execute the instructions in the correct sequence. AES-NI is available on select Intel® processors. For availability, consult your reseller or system manufacturer. For more information, see /en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni
++Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance.
ABOUT THE AUTHOR
|Aleksey is currently located at the Intel Novosibirsk R&D site in Russia located in Akademgorodok - educational and scientific center of Siberia. He has been working on Java runtime development and optimizations for the last 7 years.|