Posts Tagged ‘FIPS-140’
img
Broken USB Drives: Is Expertise Now More Critical Than Ever?
img

I’ve always liked those Holiday Inn Express commercials with the theme of “Stay Smart.” The commercials portray an “expert” stepping in to save the day. In one, a “nuclear expert” takes charge of a reactor about to melt down. In another a “doctor” arrives to deliver a baby just in the nick of time. The tag line is funny because the so-called expert turns out not to be a nuclear scientist or a doctor, but just an average person who stayed at a Holiday Inn Express. That made them “smart.” Don’t worry; I’ll bring this discussion back to encryption momentarily.

Just last month, reports surfaced of broken encryption security for some Kingston, Verbatim, and SanDisk secure USB storage devices. Not all of the vendor’s devices were affected, but some of their most popular products were. All these products were NIST-certified, causing some industry commentators to erroneously question the certification process. Being a big believer in independent certification, I’d like to weigh in on this controversy and set the record straight.

As it turns out, the weakness, in these devices, was not in the actual AES encryption, but in the key management processes. All the affected vendors quickly released replacements or patches to fix the problem, which is the right thing to do. But it was fascinating to watch some of the responses to this problem. Many commentators complained that the FIPS-140 testing was faulty, or that FIPS-140 testing was irrelevant. The implication is that FIPS-140 does not really give you any assurance of security, and therefore, also by implication, that it is not important.

This is really the wrong conclusion. Let me talk a little about FIPS-140 certification and what is does mean.

First, FIPS-140 certification is not a guarantee of security. It is an assurance that encryption and related security algorithms have been implemented in compliance with published standards, that an application uses good practices in exposing it’s operational interfaces, that start up tests validate that the application has not been modified or corrupted, that cryptographic material is not exposed in application logs or leaked to memory, and that an independent expert has reviewed the source code. Going through a FIPS-140 certification is a grueling process for an encryption vendor and almost always results in finding some issues that need to be addressed to make the product more secure. Companies that engage in FIPS-140 certifications produce better products, and become better security designers in the process.

Is the FIPS-140 testing and certification process perfect? Of course not. That’s not a standard anyone can meet. In fact, NIST is working on a project right now to enhance the process. Believe me, the new certification process (probably to be named FIPS-140-3, for version 3) will not be weaker than the current process, it will be better.

The lesson from the encrypted USB problem is not that FIPS-140 certification is meaningless. It’s that doing encryption right is really difficult. If you want a secure USB storage device, you would NEVER consider using a product that was not FIPS-140 certified. We have plenty of experience of broken security on non-certified products. Problems with certified products are rare, but do happen. Usually you will find that a problem with a FIPS-140 certified product is with some aspect of the application that was out of scope for the certification. That’s the case for the encrypted USB devices that had problems.

To bring us back full circle, I just want to say that no responsible Enterprise should trust a non-certified USB device, anymore than you or I should trust a “doctor” to perform surgery because that “doctor” stayed at a Holiday Inn Express. The sad fact is that many large corporations today are putting their trust in encryption vendors who have not FIPS-140 certified their products. The management of these companies would never consider using a $100 secure USB device without certification, but do entrust the protection of huge amounts of sensitive data to non-certified vendors. In this age where too many try to pass themselves off as experts, it often takes an organization like NIST to certify the expertise behind something as important as encryption.

I’m proud of our NIST certifications – we will never back down from our commitment to provide you with the best security products and our commitment to independent certification. You can learn more about FIPS-140 certification on our web site, or directly from NIST at www.NIST.gov.

Patrick

img
PGP Yesterday & Today
img

As business use of the Internet was taking off in mid-1998 I began hearing this consistent message from IBM AS/400 users: “We need encryption to protect our data as it moves over the Internet.” I only needed to hear this a few times before I began looking at incorporating encryption options into our file transfer applications.

My research included talking to a handful of encryption vendors, before finding an application called “Pretty Good Privacy,” or PGP. The application was the work of Phil Zimmermann and a small cohort of fellow off-the-map developers. I researched Phil a bit before contacting him, and — uh oh — I found he had been in trouble with the US government back when encryption was considered a “munition.” So it was with a little hesitation that I decided to place a call to this “outlaw” programmer.

By this time, the controversy over Phil’s activities had died down, and many of the restrictions on encryption had been relaxed. I found it surprisingly easy to get his phone number, get Phil on the phone, and see what he thought about using PGP on large systems.

We had a good conversation about PGP and its prospects for becoming a commercial standard for data protection. Phil was very helpful and we discussed some of the technical issues in porting PGP to the AS/400. He encouraged me to take the leap into the PGP project, and gave me referrals to the development team in charge of the commercial version of PGP. That call and his encouragement were crucial to our efforts over the next 10 years to bring PGP encryption to large IBM platforms.

After some twists and turns, and a few months of laboring in the trenches, we released the first version of PGP for the AS/400. The port to the AS/400 turned out to be a really big challenge. The C compiler was in its infancy, and we struggled with its limitations. And the ASCII to EBCDIC conversions were a nightmare. But we got the product released in 1999. It was very popular and remains so today. We now have hundreds of customers using PGP to protect their data.

PGP is now the de facto standard for whole file encryption in eCommerce. It is deployed by banks, insurance companies, medical suppliers, payroll servicers, and a wide variety of other organizations. Almost every organization on planet Earth deploys PGP to protect sensitive data. Phil’s vision of PGP becoming a widely accepted method of protecting data has become a reality.

Of course, PGP has been through some changes over the years. New encryption algorithms have been added such as AES and Elliptic Curve Cryptography. The product found a new home at PGP Corporation, and has undergone steady development since then. We have a great relationship with the folks at PGP, and many of them have been working with the product from the first days.

PGP Corporation recently completed a FIPS-140 certification of the PGP technology, and this was an important step. As we watch the evolution of security standards, I believe that independent certification by NIST will be crucially important in the months and years ahead. I know from personal experience that certification is hard to do and demands a deep commitment on the part of an encryption vendor. But there is no substitute for the rigor and discipline that it requires.

Here at PTSS we continue to incorporate PGP into new solutions. It’s a rock-solid platform on which to build. I’m happy to continue working with PGP Corporation, and you’ll be hearing from us soon about some of our new developments that incorporate PGP encryption.

After all these years, I’m grateful for Phil’s words of encouragement back in 1998. And am reminded to never underestimate what a few encouraging words can do. Thanks Phil!