I’ve been writing about encryption performance lately because our customers and potential customers have been asking about the impact of encryption on the overall performance on their systems.  It’s good that they are asking these questions as a poorly performing encryption library can have severe impact on your application environment. This is especially true on an IBM Enterprise platform like the IBM i (formerly known as AS/400 and iSeries) where customers often run multiple applications.

While it is common in the Microsoft, UNIX, and Linux worlds to segment different applications onto different physical servers, it is common in the IBM i world to run many applications on the same server. You typically find CRM, ERP, web, and many other applications happily co-existing on one IBM i server. But this means that a poorly performing encryption library will have a ripple impact on all of these applications, and not just one.

IBM provides a no-charge, AES software encryption library on the IBM i platform that developers can use to encrypt data. It implements all of the standard AES key sizes (128, 192, and 256) along with a variety of other encryption algorithms, both open and proprietary.  I don’t believe the software library has been independently certified to the NIST standards, but I believe that it properly implements the AES encryption algorithm.

But how does it perform?

We did a simple little comparison test of encrypting 1 million credit card numbers on an entry level IBM i model 515 server with a single processor. We compared the native IBM AES library with our own AES encryption library which is NIST certified and optimized for encryption.  The difference is very large. Our IBM i encryption library clocked in at 116 times faster than the native IBM i library. Note that this is an informal test and not independently verified, but practical experience by our customers is very similar.

What does this mean in terms of application performance when you add encryption to the mix? The math is pretty simple. An encryption task that takes 10 minutes with our library will take several hours with the IBM library. That’s painful. And all of the other applications that share this system will also feel the pain.

The problem is not limited to just an occasional developer at an individual customer site. Some vendors of IBM i software use the IBM encryption libraries, too. So you can be inadvertently using the poorly performing libraries without knowing it.

Often I see IBM i customers trying to fix an encryption performance problem by adding additional processors to their servers. This can be expensive, and usually involves software license upgrade fees. It can also not have the impact that you might think. Due to the way that encryption works, adding a second processor usually will not double your encryption throughput. Another bit of disappointment and extra cost.

It is usually not hard to fix an encryption performance problem if you catch it early. If you’ve take a modular approach to the implementation, you can usually swap out one module for another without too much difficulty. You just don’t want to be doing that for hundreds of applications.

For more information on AES encryption, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.

Patrick

Last week we hosted a webinar titled “Automatic Encryption on the IBM i” and got some great questions!  Now that IBM i 7.1 (V7R1) has been out for almost two years, we are starting to see more and more companies upgrade their IBM i’s to this latest release of the OS.  As a result, questions and concerns about FIELDPROC have been rolling in.  This feature allows organizations to automatically encrypt their data with no application changes, making it easier than ever to meet compliance regulations with encryption (PCI DSS, HIPAA/HITECH, etc.). 

Previously, encryption was a big project that often brought fear into the eyes of the IBM i administrator.  Not only do we have a FIELDPROC encryption solution that avoids the need for development, but we feel it is the best available encryption for your organization.  Performance is a key differentiator among encryption providers, and we challenge you to find a faster solution.

Additionally, we have been getting questions on how FIELDPROC affects Business Intelligence (BI) tools.  Patrick Townsend, Founder and CTO, has taken a few minutes to address some of these questions from our recent webinar. 

I have heard bad things about FIELDPROC performance.  You seem to think it performs ok.  Can you talk about that?

I think some of the less than stellar things you have heard about FIELDPROC performance comes from people who have implemented poor FIELDPROC encryption solutions.  Different encryption libraries can have very different performance results.  We have tested our optimized encryption libraries, and when compared to others, have found a 100 times difference in the speed of our libraries – even when you are doing something like 256-bit AES encryption.  I think some people have had a bad experience with encryption and FIELDPROC, and I am sure you will have a different experience with our solution. 

We make it really easy to evaluate AES/400, our FIELDPROC encryption solution.  If you have had a bad experience around FIELDPROC, you should take a look at our solution.  I think we will convince you that we have the best FIELDPROC encryption solution available.

How does FIELDPROC encryption affect OLAP reporting tools like ShowCase and Cognos?

The implementation of FIELDPROC is going to work as long as you have a standard DB2/400 database on the IBM i platform and you are running V7R1.  If you have a Business Intelligence tool that runs on top of DB2/400, then FIELDPROC will work for you.  FIELDPROC is a facility that is implemented at the database level and not on the application level.  Personally, I think that if you have sensitive data in any Business Intelligence database, the user controls and masking controls that we have implemented in our FIELDPROC encryption solution should look very good to you because it gives you the ability to maintain the power of those Business Intelligence tools without accidentally exposing sensitive data and creating additional risk.  FIELDPROC, by itself, will not do masking or user controls for you, but our implementation of FIELDPROC in our Alliance AES/400 product will do that for you and will help you protect that data.

View our webinar “Automatic Encryption on the IBM i” for more information about FIELDPROC and how your organization can easily meet compliance regulations that require encryption – with no application changes!

Before you deploy an encryption solution, there is one often-overlooked consideration to be aware of – performance.  A slow encryption solution can change a “job-well-done” into “we need to get this solution off our servers and go buy from Townsend Security STAT!”  This actually happened to a retail customer of ours.  Their initial encryption implementation was so slow that it prevented them from being able to use it in production.  True story.

So are there any performance tests you can do before you decide on a FIELDPROC encryption solution?  You bet.

Before you begin, you need to decide how many fields in a table you have to encrypt.  If you need to meet the PCI DSS compliance regulation, you might only need to encrypt one field (credit card number).  If you are protecting PHI (Protected Health Information) in the medical segment or PII (Personally Identifiable Information) for privacy notification laws, then you may have several fields in a table that need to be protected. Every column that you need encrypted is going to add to the overall performance burden.

A good first performance test is with just with one column.  We recommend creating a table with one million records, implement FIELDPROC, and then seeing how long it takes to encrypt the data in that table.  These results will give you an idea how your system will perform when you are only encrypting one field (a credit card number to meet PCI DSS, for example).

Next, if you need to encrypt several fields (ZIP code, phone number, credit card number, etc.), do a test on a table with that many fields.  You will learn a lot very quickly about the performance of FIELDPROC and your encryption solution.  If you do these tests, and we think it is absolutely important that organizations try this test before they deploy a FIELDPROC encryption solution, you will learn a lot about how the encryption will impact your production environment. 

Summary

Look at what you need to protect, try and create as close to a real-world test as you can, and see how your performance results are.  It is very simple to do.  We can even provide you with a sample database and table with a million records so that you can create and test on your machine.

Listen to our podcast “IBM i FIELDPROC Performance: Speed Matters” for more information on encryption performance with FIELDPROC on IBM i 7.1

Now that IBM i 7.1 has been available for over a year, more and more companies are finally adopting the latest OS.  It is a great release and we encourage your organization to upgrade.  As a data privacy company, the main reason we are excited about this release is because it finally allowed us to bring you automatic encryption – encryption with no application changes!  The days of modifying your applications to meet compliance regulations (PCI DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) are over.  If this sounds to good to be true, read on.

With the introduction of the FIELDPROC exit point, IBM i administrators now have something similar to what Microsoft SQL and Oracle users have had for some time.  FIELDPROC allows you to implement encryption without changing your applications.  As we attend industry events, one of the top questions we get asked is “Great!  What are the performance impacts?”  This is where the answer is “Depends.”

Any time you are doing encryption in a database environment, there are considerations about performance.  With FIELDPROC, you really have to pay attention to this question because it is an automatic facility and every time a row or record in the database is accessed, the FIELDPROC program is going to get called to do encryption or decryption.  For example, if you have 10 million records in a table and you read that entire table, you are going to make 10 million calls to a FIELDPROC program to do decryption – even if you aren’t using that particular field.  We have heard horror stories from people who have implemented poor FIELDPROC solutions and were not aware about how important investing in a proven encryption solution is.  We are very happy with the performance of our FIELDPROC solution. 

Our FIELDPROC solution uses our own NIST-certified AES encryption libraries (which is very important in many compliance requirements).  They are very highly-optimized, very fast, and have clocked in at under one second for 1 million encryptions (for more details on these tests, listen to our podcast on the topic). And as you know, the encryption library is only half of the encryption process.  The other part is encryption key management.  We have an encryption key management appliance that is FIPS 140-2 certified (again, important for meeting compliance regulations) and implements best practices for encryption key management.  Aside from your server, these components are the two things that effect encryption performance of FIELDPROC the most.

Listen to our podcast “IBM i FIELDPROC Performance: Speed Matters” for more information on encryption performance with FIELDPROC on IBM i 7.1

AES Encryption Performance: Avoid the High Cost of Poorly Performing Encryption Solutions

AES encryption has become the de facto standard for protecting data at rest in databases and unstructured data such as flat files, messages, EDI, and XML documents.  As enterprises deploy data security solutions to meet compliance requirements, they are frequently surprised by the performance impacts of encryption. Inadequate attention to encryption performance can lead to increased costs, delayed or failed projects, compliance failure, reduced flexibility to meet competitive challenges, and exposure to legal liability.

Whether you're evaluating an encryption solution or already encrypting data, these tips about encryption and performance will help ensure you have the right solution in place. 

Encryption - A Resource Hungry Application

By its very nature, encryption and decryption are resource intensive processes. Encrypting a simple credit card number requires many thousands of computer instructions. These instructions merge the input data with an encryption key using a large number of computer instructions to produce the secured data (called the “cipher text”). Because of the large number of computer instructions, an enterprise customer will experience increased utilization of computer resources and a need to consider adding additional capacity.

Ask for performance metrics

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server?

The Hidden Costs of Encryption

Poorly performing encryption solutions can come with steep price tags as you secure more data in more places. You may have to add additional memory and increase the number of processors to handle the demands of encryption. As you upgrade your server hardware, the operating system vendor and application software vendors may increase the license fees they charge for their software. These cost increases may ripple through your backup and high availability systems. On top of increased hardware and software, your human resource costs also increase as you deploy larger and more powerful servers.

Are Network Encryption Devices a Good Idea?

Some security vendors provide encryption solutions on an external server as an encryption appliance. Each time your application needs to encrypt or decrypt data, a connection to the server is created and the data is transferred to the server for the encryption operation. Be sure to understand the maximum encryption rate of these types of appliances when doing a large number of operations. if it takes 5 milliseconds to transfer data to a server for encryption,
and 5 milliseconds to return the encrypted data, that 10 milliseconds can represent a performance problem.

Test Drive - not all AES encryption solutions are the same

Townsend Security's proven AES encryption solution encrypts data 94x times faster than the competition.   Request a free 30-day trial of our popular Alliance AES Encryption and see for yourself.

But don't just take our word for it, read what Staples has to say about their experience with our AES encpryption solution.

A large multi-brand retailer, that sells its products online and in traditional retail outlets needed to meet PCI Data Security Standards for protecting customer credit card information. After evaluating several different vendors for performance they decided on AES Encryption from Townsend Security.  They deployed the Alliance AES/400 Encryption solution to protect sensitive data in DB2 database files and in a variety of unstructured data files and were able to achieve PCI compliance in record time.

Townsend Security Can Help

The best way to secure sensitive information is with strong encryption and key management. Townsend Security provides NIST validated encryption and logging solutions for the enterprise. Our encryption, key management, tokenization, and logging solutions protect sensitive data from loss, whether it is at rest or in motion.  With NIST validated and FIPS 140-2 compliant certified solutions, Townsend Security meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws.  Click here to download a free 30-day trial of our popular Alliance AES Encryption.