Wednesday Feb 03, 2016

IBM Java Applications Taking Advantage of SPARC Hardware Encryption

We’ve been talking recently about IBM’s GSKit, through which many IBM applications can automatically take advantage of SPARC Hardware Encryption (including the latest SPARC M7-based systems). We’ve since been asked whether this was also possible for Java-based IBM applications (such as WebSphere Application Server) or other applications written against IBM’s SDK Java Technology Edition to take similar advantage. This post is written to help answer those questions.

What is the IBM SDK?
IBM has traditionally licensed Oracle’s Java Runtime Environment and Java Developer Kit, modified it slightly, and released it as the IBM SDK. This combination of Java Runtime and Developer Kit is designed to support many IBM products, and can also be used for new development (although the recommended Java platform on Solaris is Oracle’s own Java Runtime Environment and Java Developer Kit). Oracle Solaris ships with both Java 7 and Java 8, but most IBM apps include the Java 7 version of their SDK.

What is the Advantage of Using Hardware Cryptography on SPARC?
Sometimes quite a bit, depending on the size of the chunks of data being encrypted and decrypted. Take this simple Java program, which does an adequate (if somewhat artificial) job at demonstrating the use of Hardware Crypto from Java:


This code simply creates an array of random data of size specified at runtime, and then encrypts using the common AES128 cypher. This algorithm happens to be one of the many accelerated by recent SPARC CPUs. When run on out-of-the-box Oracle and IBM implementations of Java 7 on SPARC, we can see the advantage to the code taking advantage of SPARC hardware crypto:



Figure 1: AES128 Encryption on SPARC M7 (no workaround)

Again, this is a very artificial test case used to make a point.The benefit from hardware acceleration will vary by workload and use case, but the key point to keep in mind is that this hardware assist is always available on SPARC M7 (the differences are proportional on SPARC T4 and T5). In those cases where it makes a difference, one should make an effort to take advantage of it.

Whither WebSphere Application Server?

IBM WebSphere Application Server v8, like other J2EE application servers, is written in Java, and could therefore in theory take advantage of the workaround described in the next section. But you don’t have to go with an unsupported solution for WAS, because Best Practice is usually to stand up the IBM’s included HTTP Server in front of WAS, and HTTP Server is built with GSKit 8. Check to see that the version of HTTP Server you use with WAS v8 supports SPARC hardware encryption – if so, you’re good to go!

How To Make Use of SPARC Hardware Crypto from IBM Java
Central to the Java Cryptography Architecture is the notion of JCA Providers, which allow developers to create and ship security mechanisms which can ‘plug-in’ to a Java Runtime via well-defined APIs. All Java runtimes ship with a default set of providers, usually found in the instance’s java.security file. Since Java 7, the OracleUcrypto provider has been provided in Solaris releases of Java, specifically to interface with the underlying Solaris Ucrypto library (part of the Solaris Cryptographic Framework). On platforms based on SPARC T4, T5, M5, M6 and M7 CPUs, the Ucrypto library automatically takes advantage of any available underlying SPARC hardware cryptography features.

Those developing Java applications on Solaris with Oracle’s implementation of Java will find that this functionality is available by default on SPARC; in fact, the OracleUcrypto provider has the highest priority in the instance’s java.security file. Here’s an excerpt from the default java.security file in Oracle JDK 1.7:



As mentioned above, Oracle’s Java implementations are recommended on Solaris, but for those developers who must make use of the IBM SDK, you’ll notice that the IBM version of the
java.security file is not quite the same as that above. In fact, it is missing the OracleUcrypto provider:



What, then, can a developer do to reproduce the desired functionality?

1) The Officially-Supported Solution

Build and deploy against Solaris 11’s built-in Oracle JDK and JRE.

2) The Currently-Unsupported Solution

As you might have already surmised, Java’s Security Provider mechanism allows for quick and easy addition or substitution of additional Crypto providers (in the cases of third-party cryptographic hardware modules. By adding the UcryptoProvider to IBM’s java.security file, Java executables will get that provider and the advantage it gives. Note: these instructions are correct for Java 7/SDK 7, but have not been tested on other major releases of Java:

Step 1: Add ucrypto-solaris.cfg to lib/security
Copy the ucrypto-solaris.cfg file from the Oracle Java 7 instance (in jre/lib/security) to the lib/security directory in the IBM SDK instance.

Step 2: Add UcryptoProvider as the first entry in the IBM lib/security/java.security file
Assuming
you add to the top of the list, and keep the existing providers, the file above would end up looking as follows:


3) The (Hopefully) Future-Supported Solution

The above workaround does indeed work, but it’s not yet supported by IBM. That’s not to say we’ve not asked for it – we’ve submitted a feature request with IBM, and the good news is that any IBM customer who would also like to see this (perhaps you?) can upvote it now!


[Link to Java code snippet above] 

Tuesday Dec 08, 2015

IBM GSKit Supports SPARC M7 Hardware Encryption

Oracle and IBM have a very close working relationship running IBM software on Oracle hardware. One of the recent results of this collaboration is the announcement by IBM that its GSKit v8 now supports SPARC M7 hardware encryption (as well as SPARC T4 and T5 processors). This, in turn, means that several IBM software products can now make use of on-chip SPARC hardware encryption today, automatically, without significant performance impact

What Is GSKit?

The IBM Global Security Kit (aka GSKit) is not a product offering in itself, but instead a security framework used by many IBM software products for its cryptographic and SSL/TLS capabilities. Example IBM products making use of GSKit today include DB2, Informix, IBM HTTP Server and WebSphere MQ. This latest version of GSKit ( aka "IBM Crypto for C" ), version 8, was validated as a FIPS 140-2 Cryptographic Module within the past earlier this year.

Obtaining The Proper Version of GSKit

GSKit is bundled with each product that makes use of it; over time, new product releases will incorporate GSKit v8 by default. Until then, the latest GSKit v8 for SPARC/Solaris is available on IBM Fix Central, for download and upgrade into existing products. Installation instructions can be found here.

The support described above is available in GSKit v8.0.50.52 and later. As of this writing, the latest GSKit v8.0.50.55 is available for download from Fix Central.

IBM Products that currently make use of GSKit v8 on Solaris (and therefore could take advantage of SPARC on-chip data encryption automatically) include (but are not limited to):

Determining Current GSKit Version

  • $ /opt/ibm/gsk8/bin/gsk8ver # 32-bit version
  • $ /opt/ibm/gsk8_64/bin/gsk8ver_64 # 64-bit version

What This Means

In many cases (such as SSL/TLS over-the-wire communication), products using the proper version of GSKit on Solaris/SPARC will automatically take advantage of hardware encryption. Situations with larger client-server packets will benefit more than those with small packet sizes.  

This will allow these products to make use of the increased security that encryption offers with extremely low performance overhead (something that is not possible with software-only crypto or hardware crypto on other platforms).

Because each of these IBM products has specific use cases, we'll cover more details for each in future blogs.

Monday Dec 07, 2015

End-to-End Security: Solaris 11, SPARC M7 and the ISV Ecosystem

You'll be seeing quite a bit on this blog about increasing security of your applications in the coming weeks and months. Before that, however, before we dive into the specs and numbers, the wonders of CPU features, the software technologies that protect -- it is worth setting some overall context.  

Security is more than just data encryption. Indeed, security is more than any single feature, technology or product. Security, as much as anything in the IT world, must be addressed, planned-for and administered both in the whole, as well as the details. Security must be considered from beginning to end or -- as we engineers like to say -- "end-to-end". Holistically. The Big Picture. Soup to Nuts. You get the idea.

Because, in truth, while any single component of a system can provide state-of-the-art security for its little realm, the entire system is only as secure as each and every component. Your on-disk encryption can be unbreakable, but if your system uses weak passwords on internet-facing portals, your company could be the next featured New York Times data breach story.

Within the Oracle Systems Group, we get that. We understand that it takes more than algorithms and firewalls. That's why we'll be talking about Best Practices. About Security Compliance. About Industry and Governmental Security Standards. About hardware encryption. About all the roles in the development, deployment and use of a system. About the pieces of a system which, in total, is 'end-to-end secure'.

With the recent announcement of SPARC M7, Oracle now has the most compelling End-to-End Security platform for the Data Center. These new SPARC-based servers, with on-chip Security in Silicon, and running the Solaris 11 Operating System provide the following enhancements:

  • Silicon Secured Memory: For the first time, Silicon Secured Memory adds real-time checking of access to data in memory to help protect against malicious intrusion and flawed program code in production for greater security and reliability. This protection is available to third-party software developers via application programming interfaces.

  • Hardware-Assisted Encryption: Built into all 32 cores, this feature enables data encryption without performance penalty. This gives customers the ability to have secure runtime and data for all applications even when combined with wide key usage of AES, DES, SHA, and more. Existing applications that use encryption will be automatically accelerated by this new capability including Oracle, third party, and custom applications.

  • Built-in Solaris Compliance Tools: Oracle Solaris 11 lowers the cost and effort of compliance management by designing security features to easily meet worldwide compliance obligations; documenting and mapping technical security controls for common requirements like PCI-DSS to Oracle Solaris technologies with a simple-to-use tool that provides not only reporting but also simple instructions on how to mitigate any compliance test failures; and providing compliance report templates. The compliance system is standards based (XML) and built on the SCAP ecosystem (XCCDF, OVAL, and SCE), which easily integrates with enterprise wide compliance management programs. 

Saturday Dec 26, 2009

Reminder: Tech Webinar on Security for Web Application

Reminder: Wednesday January 27th, Join the Sun Startup Essentials Webinar on  Security for Web Applications.[Read More]

Monday Dec 07, 2009

Tech Webinar: Security for Web Application

Wednesday January 27th, Join the Sun Startup Essentials Webinar on  Security for Web Applications.[Read More]
About

Application tuning, sizing, monitoring, porting on Solaris 11

Search

Categories
Archives
« February 2016
SunMonTueWedThuFriSat
 
1
2
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
     
       
Today