Improved Advanced Encryption Standard (AES) Crypto performance on Java* with NSS using Intel® AES-NI Instructions

BACKGROUND

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


¹http://www.mozilla.org/projects/security/pki/nss/

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.

METHODOLOGY

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.
Build NSS
  • For RHEL* Linux, unpack and go to NSS_PATH/mozilla/security/nss
  • Run “make BUILD_OPT=1 USE_64=1 nss_build_all” , where USE_64=1 for x64 systems
Configure JDK
  • Get all *.so files from NSS_PATH/mozilla/dist/LinuxXXXX_glibc_PTH_64_OPT.OBJ/lib and put NSS libs into separate folder (NSS_LIBS_PATH) on the same system
  • Set LD_LIBRARY_PATH to the folder path with NSS binaries NSS_LIBS_PATH



Step 2: Update JRE Security Providers
Update JRE
  • Modify the list of providers in java.security (located at JDK_PATH/jre/lib/security folder)
  • Add NSS as first crypto provider and increment other crypto providers’ numbers:
    • security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg security.provider.2=sun.security.provider.Sun
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:
name=NSS
nssLibraryDirectory=$NSS_LIBS_PATH
nssDbMode=noDb
attributes=compatibility




² http://docs.oracle.com/javase/6/docs/technotes/guides/security/p11guide.html

* $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
Possible Issues

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:

  • Cipher cryptoCipher = Cipher.getInstance(“AES/CBC/PKCS5Padding”);

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.

PERFORMANCE BENEFITS

Standard Benchmark++

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.


³ http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html#NSS

Micro Benchmark++

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
4k 5x
64k 7x
128k 8x

Data block Intel AES-NI on / Intel AES-NI off (128-AES-CBC) decrypt
4k 8x
64k 16x
128k 18x

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.

SUMMARY

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.

TERMINOLOGY

Term Description
AES Advanced Encryption Standard
AES-NI AES New Instructions
JDK Java Development Kit
IDE Integrated Development Environment
BKM M Best Known Method




4https://wiki.mozilla.org/FIPS_Validation

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.
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.