What is NIST?

The National Institute of Standards and Technology (NIST) is a US government agency that is a part of the Department of Commerce. The NIST sets non-military government standards for a wide variety of techn ologies including data encryption. Because the NIST uses an open and professional process to establish standards, the private sector usually adopts NIST standards for commercial use. The NIST is one of the most trusted sources for technology standards.

What is AES?

The Advanced Encryption Standard (AES) is the standard for data encryption adopted by the NIST in 2001. This encryption standard replaced the earlier Data Encryption Standard (DES). The DES encryption standard became weaker due to the advancing power of computer systems. The NIST began a process in the late 1990’s to find a replacement for DES. After a lengthy examination of several alternatives, the AES standard for encryption was adopted and codified as FIPS-197. AES encryption is now the de-facto standard for strong data encryption.

What is AES Validation Testing?

NIST sets the standard for AES encryption testing, and charters independent labs to administer and oversee the testing process. Through the National Voluntary Laboratory Accreditation Program (NVLAP) the NIST certifies independent testing labs for the Cryptographic Module Validation Program (CMVP). Data security software vendors administer the tests, validate the results, and submit the results to the NIST for acceptance. Software vendors work with an independent certification laboratory and not with the NIST directly.

The NIST established five methods, or modes, of encryption that can be used with AES. These are Electronic Code Book (ECB), Cipher Block Chaining (CBC), Counter (CTR), Output Feed Back (OFB), and Cipher Feed Back (CFB) modes. There are separate tests for each mode. A software vendor can choose to validate on only one mode, a subset of the five modes, or all modes of encryption. In addition, the NIST defines three key sizes for encryption: 128-bit, 192-bit, and 256-bit keys. A software vendor can choose from one to three key sizes to certify.

Most software vendors choose to certify just one or two modes of encryption, and on one key size. The Alliance AES Encryption products are certified on ALL five modes of encryption, and all three key sizes.

Certification Means Strong Encryption

NIST certification is your assurance that a vendor’s AES encryption solution implements data encryption the right way. There are many ways to use encryption and a wide variety of modes of encryption. Improperly implemented solutions may work for one type of task, but fail under different application requirements. All software vendors claim they implement strong encryption. Can they prove it? Ask them for their NIST certification.

Certification Means Compatibility

One of the biggest challenges facing Enterprise customers is encrypting and decrypting data on a variety of platforms. Data may be encrypted in an Oracle database, then transferred to Microsoft SQL Server, then to an IBM i (AS/400) platform. Computer vendors use different methods of encryption, and different modes of encryption. How can you be sure that your encryption solution will be able to handle all of your requirements?

The NIST certification provides the assurance you need that your software is up to the task. Certified software must work the same way for all of the NIST defined encryption tasks.

The Alliance AES solutions provide even more assurance of compatibility – Alliance AES solutions are certified on all key sizes and all modes of encryption. No other data security vendor provides this level of certified support.

Alliance AES Encryption on Every Enterprise Platform

The modern Enterprise uses a wide variety of server platforms from a number of different vendors. In addition, data is exchanged with customers, vendors, and service provides outside the organization. To meet these challenges the Alliance AES Encryption products are certified and available on all Enterprise platforms including:

•  Microsoft Windows (2000/XP/2003)
•  Linux (SUSE and Red Hat, on Intel and POWER)
•  UNIX (AIX, Solaris)
•  IBM i (AS/400, iSeries)
•  IBM z (mainframe)

All of the certified Alliance AES encryption solutions work the same way on every platform.

Townsend Security is currently offering a free 30-day evaluation of the Alliance AES encryption solution for your platform.

Emerging Data Privacy Regulations

Organizations need to comply with an increasing number of data privacy regulations.  In addition to regulations such as PCI, HIPAA/HITECH, GLBA/FFIEC, and Sarbanes-Oxley, states are passing their own privacy laws.  For example, Massachusetts says that if you are doing business with anyone in their state, you must comply with their privacy law – even if your business is located across the country.  NIST-certified encryption and key management can help meet these emerging regulations.

I recently sat down with Patrick to discuss the emerging data privacy regulations - as well as how to meet them and what it is like to have an audit. 

There are lots of different data privacy regulations for people dealing with sensitive information.  Can you speak a little about each one?

You are right.  There are a lot of regulations and companies are finding themselves falling under more than just one.  Probably the one that most people know about is the PCI Data Security Standards (PCI DSS).  Any organization that accepts credit cards for payment falls under these regulations.  In the medical segment we have the HIPAA and HITECH Act, which sets the standards for protecting patient information.  In the banking and financial area we have the GLBA and FFIEC regulations which cover a broad set of financial institutions.  FERPA is for educational institutions.  Sarbanes-Oxley (SOX) covers any publicly traded company.  Finally, we have state privacy laws on the books and there are about 44 or 45 of them.  So you are right, there are a lot of different privacy regulations and there are over-lapping and different requirements for each regulation.

So, an organization can be faced with several different compliance regulations, is there any common solution?

You need to be aware of each one, though there are some overlapping definitions of what constitutes Personally Identifiable Information (PII).  It is important to follow proper encryption and key management best practices and make sure your solutions are NIST certified.  State Privacy Laws are starting to follow PCI guidance.  It is important to note that State Privacy Laws are now starting to extend beyond the boundaries of the state.

Do any of these regulations have any real “teeth”?

Oh, yes!  A data breach can have lasting financial and business impacts.  Just ask the companies who have had major data breaches.  One credible study by the Ponemon Institute estimates that TJ Maxx may eventually spend a total of about 9 billion dollars (yes, that’s billion with a “B”) as a result of their data breach.  There have been numerous fines levied against merchants, medical providers, and businesses related to data security breaches.  There are real financial penalties for these breaches.

Less well known is the fact that an embarrassing data security breach can sink your business.  If a big part of your business is based on Internet sales, for example, you can find your business disappearing in the event you have a data breach.

What is the process of undergoing an audit like?

Don’t panic.  It can be painful, but in most cases and audit involves a routine set of questions.  You can actually prepare for that experience.  It is good to know the configuration of your network and where things stand in terms of data protection.  Having good documentation on your policies, procedures, your network, and your business applications is going to be very helpful in an audit.  Also, you should see your auditor as an important partner in compliance.  A good relationship with an auditor will help get you through the process.  You can see your auditor as someone who can really advise you on best practices for securing data.

Also, your software supplier can be an important partner.  For example, we offer a lot of questions about compliance regulations and best practices when we work with our customers and prospective customers – trying to get them educated on what really is best practice.

Are there any emerging regulations that our listeners should be aware of?

Congress is working on a Federal Privacy law that would replace the 44 or 45 state privacy regulations. Businesses struggle to keep up with the differences between all of the state laws, and there is business support for passing a federal law. A version has passed the House of Representatives, and there are two or three versions pending in the Senate. These will have to get consolidated into a single law, and then rationalized with the House bill. But eventually I think this will happen.

I think we can make some predictions about how a new federal law will affect businesses. We already have a template in the HITECH Act of 2009. I suspect that the FTC or some other federal agency will be tasked with defining the data security regulations. It is highly likely that the National Institute of Standards and Technology (NIST) will be the basis for standards and certification of solutions. Then there will be published rules and guidelines on how to implement data protection.

If I am right about this, it will prompt businesses to be sure that their data protection solutions meet NIST standards. And I don’t mean sorta, kinda, maybe. You need to find solutions are NIST certified to FIPS-140-2 or similar standards with the paper certificates to prove it.

Download a 30-day evaluation of NIST-certified AES database encryption from Townsend Security

The Importance of NIST Certification for AES Encryption

Download a Free Trial Now

All Encryption is Not Created Equal

The National Institute of Standards and Technology (NIST) defines the standard for AES encryption, and provides a rigorous testing process for software vendors. The certification process is carried out by independent testing labs who report the results to NIST for validation.  The AES certification process tests every aspect of encryption and involves millions of encryption and decryption operations. Only the most dedicated security vendors are able to pass the tests and achieve NIST certification.  Townsend Security has achieved AES Validation for all key sizes and modes of operation, on every major Enterprise platform. 

How important is NIST validation?

Steve Tenore, a Senior IBM i Consultant for Staples, says "Staples wouldn’t even consider a vendor solution that didn’t have NIST certification. The fact that Townsend Security has NIST certified solutions on the major Enterprise server platform was a big plus."

Need encryption done right?  Insist on NIST.

In a study of the certification program, NIST found nearly 50 percent of software vendors had errors in their encryption solutions. It isn’t easy to get encryption right. A certificate of validation from NIST is your assurance that AES encryption does what it is supposed to do. Every time.

Certification Means Stronger Encryption

NIST certification is your assurance that a vendor’s AES encryption solution implements data encryption the right way. There are many ways to use encryption and a wide variety of modes of encryption. Improperly implemented solutions may work for one type of task, but fail under different application requirements. All software vendors claim they implement strong encryption. Can they prove it? Ask them for their NIST certification.

Certification Means Reliability

The NIST testing process is designed to exercise a vendor’s encryption solution under stress conditions. Large numbers of repeated encryptions are performed with the output of one encryption used as input for the next encryption. Failures in memory management or reliability will be exposed in the testing process. Encryption software may work without errors for 100 or 1,000 encryptions, but will it work on 1 million encryptions? How about 100 million encryptions?

No one wants the unpleasant experience of a system failure due to unreliable software. NIST certification helps provide some assurance of a reliable implementation. 

Download a free trial of our AES Encryption (available for IBM i, IBM z, Windows, Linux, and UNIX) and be guaranteed that you are using the most secure and best performing encryption available.

How Much Data Can You Encrypt with RSA Keys?

When someone first begins to consider using encryption to protect business data, they discover that there are two general types: symmetric (AES) and asymmetric (RSA). At first glance, which one you would choose can be confusing.

One of the differences between the two is speed. Symmetric encryption is much faster than asymmetric. The exact difference is implementation dependent, but may be on the order of 100 to 1000 times faster.

It is widely known that AES encrypts a 16-byte block of data at a time. However, how much data can be encrypted at one time with an RSA key is usually only discussed in vague terms such as “use RSA to encrypt session keys.” This raises the question of how much data can be encrypted by an RSA key in a single operation.

The typical encryption scenario is to encrypt with a public key and decrypt with the private key. OpenSSL provides the RSA_public_encrypt and RSA_private_decrypt functions to implement this.

The first parameter to the RSA_public_encrypt function is flen. This is an integer that indicates the number of bytes to encrypt. Its maximum value depends on the padding mode. For OAEP padding, recommended for all new applications, it must be less than the size of the key modulus – 41 (all in bytes).

To get the size of the modulus of an RSA key call the function RSA_size.

The modulus size is the key size in bits / 8. Thus a 1024-bit RSA key using OAEP padding can encrypt up to (1024/8) – 42 = 128 – 42 = 86 bytes.

A 2048-bit key can encrypt up to (2048/8) – 42 = 256 – 42 = 214 bytes.

Additional Resources for IT Developers and Professionals

We collaborate with developers and IT professionals around the world and know that they use a wide variety of languages and platforms to accomplish their work.  Our products include documentation, source code examples, and HOWTO guides for developers in order to help projects get done quickly. Visit our Developer Resources section of our web site to learn more and discuss your upcoming project with our development team.

 

 

As day three of the RSA Conference 2011 begins, it marks the half-way point through the largest data security tradeshow that the industry has to offer. Walking into the show you would be hard pressed to tell whether you walked into a security show or a grown up play-yard. Look to left you see sumo wrestlers, looking ahead there are unicycles weaving the crowd, and to the right are pirates handing out candy. And to top it all off, each night ends with beer, wine, and appetizers for all attendees. Who wouldn’t want to attend the RSA Conference 2011??!!

As you look past all the gimmicks, the technology is still really what matters.

A noticeable change over the past two years is the increased awareness of FIPS-140 certification for key managers.

We believe this is largely driven by compliance auditors whose demands have evolved from "you must encrypt" to "you can't store your keys with your data" to "you need to use a key manager" and are now converging on "you need a FIPS-140 certified key manager."

As the auditing community matures we expect the requirements for formal government certifications to move from occasional to manditory.

In the past we usually only heard these concerns from sophisticated security architects with very large companies. Now we are seeing this awareness beginning to move through the SMB marketplace.

Prospective partners, future clients and current customers recognize that Townsend Security has done encryption and key management the way that it needs to be done – and proven by NIST and FIPS certifications. If your encryption offering hasn’t been reviewed and certified by NIST, you have no assurance that you aren’t implementing a less than secure product. “I wouldn’t consider an encryption solution that isn’t certified by NIST” is a common statement by attendees at our booth.

Would you like to see first hand how certified encryption and key management will work at your organization? Click on the links to request evaluation versions of AES encryption and Key Manager. One of our security specialists will be in contact with you to make sure you are up and running and answer any questions that you might have.

Or, if you just would like to learn more about encryption and key management, visit the resources section of our web site.

And if you read this while you are still at the RSA Conference 2011, stop by our booth and pick up a little somethin’ special that we have been saving you.

In our encryption practice we often help customers integrate the exchange of encrypted data between different applications within the organization, and between their own applications and a vendor’s or customer’s application. It is truly amazing to me how often we encounter non-standard encryption that makes this integration very difficult. The problem is not the lack of standards for encryption. Most compliance regulations provide clear guidance and references to encryption standards. Here is what the PCI Data Security Standard (PCI DSS) Navigation Guide says about encryption (my emphasis):

The intent of strong cryptography (see definition and key lengths in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm).

Strong Encryption:
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

The problem seems to be a general lack of knowledge about encryption. And this applies to some vendors of encryption solutions. Here are a couple of examples:

One of our customers was having trouble decrypting a field with our software that was encrypted on a Windows server with “256-bit AES using CBC mode”. That seemed to be a pretty straight-forward task. Yet we couldn’t get the data decrypted properly. The output just looked like garbage. We spent a fair about of time with the customer verifying that they had the right decryption key, that the initialization vectors for the decryption were specified correctly, and that our software was being used correctly. But nothing was working. We then asked the third party software vendor to share their AES source code with us.  In this case the vendor was very accommodating and let us review their source code implementation of AES encryption.

Voila! The source code showed that the implementation was using a 256-bit block size for the encryption algorithm. The AES standard (FIPS-197) requires the use of 128-bit block sizes. The use of the larger block size meant that this was not even AES encryption according to the industry standard. The vendor fixed their implementation and the project was successful. But our customer spent a lot of time and money resolving the problem.

Another example of getting into trouble occurred with a customer who deployed an AES encryption solution that used the CUSP mode of encryption. This rang alarm bells right away.  We knew that CUSP was not one of the NIST approved modes of encryption, and we had never encountered it before. We quickly learned that CUSP stood for “Cryptographic Unit Service Provider” and was implemented by IBM in a couple of their server products. This customer had a couple of problems. CUSP mode was not a standard mode of encryption, and data encrypted with CUSP was not going to be decrypted by any of the standard open source or commercial products in the market. So this customer was locked into an incompatible encryption strategy.

The second problem is that the CUSP mode of encryption is a proprietary protocol.  The PCI DSS clearly states that strong encryption must be based on industry standards and not proprietary protocols (see above).  As I interpret the PCI DDS requirements for encryption, a customer using CUSP mode would be out of compliance. That’s going to hurt the next time a QSA takes a hard look at your encryption implementation.  We recently published a white paper on the weaknesses of the CUSP mode of encryption.  Click here to download it.

One way to insure that your AES encryption software is compliant is to look for a NIST certification. A NIST AES Validation certificate, or a NIST FIPS-140 certificate, is pretty good assurance of compliance. The FIPS-140 certification process requires AES Validation, so that certification is incorporated by reference. That’s why either certification will give you the assurance that AES encryption is being done according to the standard. Lacking certification, you are relying on the promises of a vendor or developer who may be ignorant, or have a motivation to be less than forthcoming. Not a good situation to find yourself in.

Both of these customers spent a fair amount of money fixing the problem.  An entirely avoidable expense.

Patrick

The advent of faster and faster computers poses a never ending challenge for encryption methodologies. An excellent example of this is the demise of the DES encryption standard in 1999.  That was when a group of programmers was able to break the security of a DES key in about 22 hours using a brute force attack which simply tried every possible value of the key. Computers have gotten a lot faster since then! This exploit lead to the adoption of AES as the new standard for symmetric encryption.

This year marks another milestone regarding the use of RSA keys. These are the public-private key pairs that are used in the creation of the SSL/TLS connections that enable ecommerce to transactions to run over the Internet (for example when you engage in electronic banking or give a credit card number to an on-line merchant).

In the past the use of RSA keys with a length of 1024-bits was quite common. However, the official policy has changed. NIST (the National Institute for Standards in Technology) now recommends that 2048-bit keys be used to encrypt data through 2030. After that time 3072-bit keys will be required.

This is documented in NIST Special Publication 800-57, Recommendation for Key Management. See “Table 4: Recommended algorithms and minimum key sizes” for particulars.

One clear direction I’ve observed over the last few months is the focus of QSA auditors and other security professionals on the protection of sensitive data AFTER it traverses the Internet and then lands in a database on a hard disk drive. We have really good ways of protecting data in transit using 128-bit SSL encryption. For example, the web protocols HTTPS and FTPS provide for the ability to encrypt the data in transit, and Secure Shell SSH also provides strong encryption. But after the data reaches the end point of its journey it lands on a hard drive somewhere, and it is often exposed to loss at that point. I believe that’s why security auditors are putting a lot of emphasis now on making sure that data is encrypted when it hits a hard drive.

Many companies have implemented web services in combination with the XML data standard to take advantage of low cost, real time integration with their customers and vendors. When you combine the ubiquity of the web HTTPS protocol with the W3C XML standard you get a power incentive to use this platform for business integration.
 
But care should be given to what happens to data when it leaves the realm of encrypted transit and lands on server hard drives.

Of course, the right thing to do is encrypt sensitive data before it lands on the hard drive. This means that the tools you are using have to support encryption as a natural part of the process of converting XML data. Standard XML processing tools such as Xerces and Xpath do not have built-in encryption. The same is true for XML toolkits and APIs provided by IBM, Microsoft, and others. This leaves it to developers to try to intercept data after it is transformed from XML and before it lands in a database table or on a hard drive. That’s a real challenge.

In our Alliance XML/400 web services product on the IBM platform we built encryption right into the data transformation process about four years ago. Alliance XML/400 customers can protect sensitive data by just enabling the encryption option on a translation map. The solution does the rest. The data is encrypted before insertion into the database and there is no exposure as the data lands in the database on the hard drive. Our customers are taking advantage of this feature to meet PCI and other compliance regulations.

For non-IBM System i environments we now provide an easy way to retrieve encryption keys and perform encryption in a variety of development languages such as Microsoft .NET, Java, and C/C++.

Encryption can help protect against another common threat, too. At the annual PCI SSC standards council meeting in Orlando this year, forensics expert Chris Novak of Verizon talked about how more than 75 percent of data loss events begin with a well known weakness that hasn’t been patched, and half of these are based on SQL injection attacks. With SQL injection, the attack on your servers starts with bad data inserted into a database in the clear, leaving open a later exploit. There are ways to prevent SQL injection through programming techniques, but encryption will also help defeat them.

Will encrypting your data provide all of the security protection you need? Certainly not. I like to think of it this way:  Wearing a parachute on a skydiving expedition is no guarantee that you won’t be hurt when you land.  But that doesn’t mean you wouldn’t wear one, right? I think of encryption in the same way.

To view a replay of a recent webinar we presented on XML & Web Services, click here.

Patrick