Java Cryptography on Intel Westmere

      3 Comments on Java Cryptography on Intel Westmere

When it comes to Java cryptography based application security –  Solaris has significant performance advantage over Linux and Windows on Intel Westmere processor equipped servers.  I am not debunking Linux performance on Intel but evidently Linux does not take advantage of Intel Westmere’s AES-NI instructions when the Java applications relies on Java cryptographic implementations  for performing AES encryption/decryption functions.  AES is one of the most popular symmetric-key encryption algorithm widely used in security transaction protocols (SSL/TLS, IPSEC),  Disk encryption,  Database encryption,  XML Web Services security standards (WS-Security) and so forth. If you are a Java  security enthusiast or a developer who is curious about Intel Westmere and Java security – here is some observations:

Intel introduced the new 32nm Westmere processors family (Xeon processor 5600 series) that incorporates  instructions for AES algorithm (AES-NI) to faster cryptographic applications that uses AES – a symmetric-key encryption standard.  AES is a block cipher, with a fixed block size of 128 bits that encrypts and decrypts data using multiple rounds where the number of rounds (10, 12, or 14) depends on the keysize (128, 192 or 256 bits). The Intel’s AES-NI implementation consists of seven new instructions for AES  algorithm – AESENC, AESENCLAST, AESDEC, AESDECLAST, CLMUL, AESIMC, and AESKEYGENASSIST to support performing computations for 10 (128 Bit), 12 (192 Bit), and 14 (256 Bit) rounds and most operational modes including ECB, CBC and CTR.  AES-NI accelerates AES based encryption/decryption operations in the CPU by offloading them from the software and eliminates its time spent in AES encryption/decryption functions. This means applications relying on AES algorithm can delegate its AES encryption/decryption functions to Intel’s AES-NI.  To enable applications make use of Intel AES-NI, it is critical that the applications must be recompiled to use Intel’s Integrated Performance Primitives (Intel IPP) library that contains functions and optimizations for achieving AES performance using AES-NI on Intel Westmere processors. Assuming the applications are recompiled and optimized to include Intel’s IPP library – applications can benefit from AES-NI features of Intel Westmere.

Intel Westmere - AES-NI (Source: pcsstats.com)

Intel Westmere – AES-NI (Source: pcsstats.com)

Java Security: The Solaris Advantage

With the release of Solaris 10 Update 8 and above,  Solaris 10  introduced support for Intel AES-NI through integration with Solaris Cryptographic Framework (SCF).  As Solaris Cryptographic Framework acts as the intermediary for cryptographic operations, all applications relying on Solaris based PKCS#11 provider APIs, CLIs and Solaris kernel modules will automatically take advantage of AES-NI instructions for AES encryption and decryption. More importantly, with AES-NI integration –  Java SE/Java EE applications using JDK’s SunPKCS11 provider for supporting Java Cryptographic Extensions (JCE) and Java Secure Socket Extensions (JSSE),  applications using OpenSSL with Solaris PKCS11 and Mozilla NSS  with Solaris PKCS11 automatically use Intel AES-NI accelerating AES encryption/decryption operations on Solaris.

By default on Solaris, the Sun JDK and its JCE provider environment uses a Sun PKCS#11 implementation (SunPKCS11) that allows Java applications to access Solaris managed software/hardware cryptographic services. The SunPKCS11 provider is a Java based PKCS#11 implementation that integrates with underlying Solaris PKCS#11 implementations provided by the SCF and its exposed cryptographic providers (ex. Intel AES-NI). In a typical JDK installation on Solaris, the Java runtime environment is pre-configured to make use of the SunPKCS11 provider. To verify this refer to the Java security properties file located at $JAVA_HOME/jre/lib/security/java.security properties file and make sure it identifies SunPKCS11 as the default provider.

security.provider.1=sun.security.pkcs11.SunPKCS11     ${java.home}/lib/security/sunpkcs11solaris.cfg

The $JAVA_HOME/jre/lib/security/sunpkcs11-solaris.cfg file contains the configuration information used by the SunPKCS11 provider for accessing the SCF.  To leverage AES-NI acceleration, it is important to enable and enforce delegation of the required cryptographic mechanisms to the underlying Solaris PKCS#11 provider that facilitates the AES-NI acceleration support. Make sure to include the required AES mechanisms (ex. CKM_AES) in the Java SunPKCS11 provider configuration file that lists as part of  enabledMechanisms  list or removes the mechanisms from the list of disabledMechanisms  of the Java SunPKCS11 configuration file. Doing so forces the required AES operations  performed by Intel AES-NI.

For SSL scenarios using AES for bulk encryption,  it is important that the Java application server’s SSL configuration is enforced to use

TLS_*_AES* cipher suites (-Dhttps.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA)

For WS-Security scenarios using AES for XML Encryption scenarios, it is required to choose WS-SecurityPolicy using algorithm suite that includes AES ciphers. If the WS-SecurityPolicy specified algorithm suite is Basic256Rsa15, it uses Aes256 encryption and Rsa-oaep-mgf1p for key wrap. To enable acceleration, you need to remove the required bulk encryption algorithms in the disabledMechanisms list that forces those operations (ex. CKM_AES) performed by Intel AES-NI.

AES-NI Performance on Solaris for SSL and WS-Security

As I tested on a Xeon 5660 based server, using AES-NI for securing Java EE applications and XML Web services on Solaris 10 Update 9 showed significant SSL and WS-Security performance gains on Solaris 10.  The SSL performance (RSA-1024/AES-256) showed 30% – 40% performance gain over not using AES-NI and WS-SecurityPolicy (using Basic256Rsa15) showed about 2X – 3X performance on XML encryption and decryption operations.  Certainly Java security applications has strong advantage while running on Solaris on Intel Westmere processor based servers.

I am not a performance guru…but in my opinion Java Cryptographic performance on Linux (Intel Westmere) has NO EFFECT as Linux lacks support for a software PKCS#11 provider that takes advantage of AES-NI.  If your Java applications has significant AES workloads then Solaris 10 is ideal choice on Intel Westmere based servers.

Try it out and let me know your comments.

 


3 thoughts on “Java Cryptography on Intel Westmere

  1. Daniel Garcia

    Great article. I did notice that Linux on Westmere has no effect on AES operations while using JCE. I am surprised why Intel does not provide IPP for Java to support AES-NI ?

    Can I still download Solaris on Intel from Oracle web site ?

    Reply
  2. Martin Franz

    Hi Ramesh,

    thanks for this article! When I came across it I directly tried to test it. I have set up a fresh Solaris 11 using Java 1.6.0_26 on a machine with core i7-2600, with AES-NI enabled. I ran the AES example by Rags Srinivas from

    http://java.sun.com/developer/technicalArticles/Security/AES/AES_v1.html

    in a loop with 1 million iterations. Compared to a program run on a Windows7 (same machine), the Win7 runs about 5 times faster (this scales with different test sizes etc).

    I checked the security.provider as described in your article, and other benchmarks indicate that java performance is about the same on solaris/windows, but the AES experiments fail. Do you have any ideas could be going wrong?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *