Townsend Security Data Privacy Blog

The internet has become a portal for the transmission and storage of sensitive data. Most websites today gather information from potential or current customers, clients, and users. From credit card numbers to email addresses and passwords, few websites exist today that don’t collect some sort of personal data. Therefore, website developers are becoming more and more interested in learning how to build websites that can easily encrypt sensitive data that their client’s website may be collecting.

Encryption isn’t as widely used at the application and module level in websites as it probably should be. Protecting sensitive data using strong encryption from the moment a website accepts a customer’s information, and throughout transmission and storage of that data is the only method to ensure that data is never compromised. This is critical for websites using commerce modules or forms that collect a person’s health information, financial information, or other personally identifiable information (PII); and for businesses who wish to avoid a data breach.

As Drupal grows and more Drupal developers are beginning to interact with larger clients, the need to provide strong security to those businesses grows as well. The need for encryption will continue to grow as potential clients ask Drupal developers for standards-based security solutions that will help them meet compliance regulations and mitigate risk.

• Government websites, for example, will need to pass FISMA regulations around encryption.
• Large retail websites will need to pass Payment Card Industry Data Security Standards (PCI DSS).
• Colleges and Universities have multiple compliance requirements, as well as FERPA, to adhere with.

Helping clients meet compliance regulations will also require, in some cases, the need for encryption key management. Historically, developers only had three choices for encryption key storage: they could store the key in a file protected on the server, in the Drupal database, or in Drupal’s settings file. None of these options are secure, and would not meet several compliance regulations and general security best practices.

Encryption key management is more than a “key storage” solution. An encryption key manager protects encryption keys on a separate server (located in the cloud or as a physical Hardware Security Module (HSM) or in a (VMware) virtual environment) that implements control layers such as dual control and separation of duties. An encryption key manager manages encryption key creation, deletion, lifecycle, rollover, and archival. Key managers that are FIPS 140-2 compliant have undergone NIST validation and are based on industry standards. Choosing an encryption and key management solution based on standards will ensure your solution will stand up to scrutiny in the event of a breach.

If you are a Drupal developer, you can now join the Townsend Security Drupal Developer Program, work with our encryption and key management technology free of charge, and learn how to secure sensitive data in Drupal for your clients concerned with security.

Using Key Connection for Drupal, the first encryption & encryption key management module, Drupal developers can now build NIST compliant AES encryption and FIPS 140-2 compliant encryption key management into their Drupal websites.  

Just click below to sign up:

 

The time required to crack an encryption algorithm is directly related to the length of the key used to secure the data.

Every now and then, our development team comes across someone still using antiquated DES for encryption.  If you haven’t made the switch to the Advanced Encryption Standard (AES), let’s take a look at the two standards and see why you should!

Data Encryption Standard (DES):

DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005 [although NIST has approved Triple DES (3DES) through 2030 for sensitive government information].

The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.

To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).

• The DES I contest (1997) took 84 days to use a brute force attack to break the encrypted message.
• In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was "The unknown message is: Many hands make light work". The second challenge took less than three days, with the plaintext message "It's time for those 128-, 192-, and 256-bit keys".
• The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation's Deep Crack computer (built for less than $250,000) and distributed.net's computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read "See you in Rome (Second AES Candidate Conference, March 22-23, 1999)", and was found after checking about 30 percent of the key space...Finally proving that DES belonged to the past.

Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

Advanced Encryption Standard (AES):

Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES. In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.

One of the original requirements by the National Institute of Standards and Technology (NIST) for the replacement algorithm was that it had to be efficient both in software and hardware implementations (DES was originally practical only in hardware implementations). Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous. Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).

Comparing DES and AES

So the question remains for anyone still using DES encryption…
How can we help you make the switch to AES?

In light of the public revelations about the NSA’s attempt to weaken encryption standards including the random number generation standard named Dual_EC_DRBG (NIST Special Publication 800-90), and the recommendation by RSA Security to their customers to avoid using this algorithm, it is natural that our customers would ask if we are using this technology in our products.

I can confirm that we are NOT using this algorithm in any of our security products including our flagship enterprise key management solution, Alliance Key Manager. Further, the secure TLS connections for key retrieval and encryption services only allow 2048-bit RSA encryption. We do not allow the negotiation of other, potentially weak, connection methods. We implement strong cryptography in our solutions, we maintain all of the source code for our applications, our source code is independently reviewed by security professionals and cryptographers, and our solution is FIPS 140-2 validated by a NIST-certified testing laboratory. There are no known weaknesses in our encryption and key management applications and processes.

I am encouraged that NIST has opened a public review of the Dual_EC_DRBG standard and am fully confident that they will resolve any security issues that exist in the standard using an open, public review process.

I have full confidence in the security professionals at NIST. I have watched their work over many years, benefited from their guidance and diligence in the area of security, and consider them to be some of the most honorable, intelligent, and hard working members of the security community. We owe them the chance to do what they do best - review the standards, bring the best minds to the process, and publish credible and defensible standards.

Patrick

SHA-1 is perhaps the most often encountered hash algorithm in use today. But its use in digital signatures will be restricted by NIST in the near future. NIST has already restricted use of SHA-1 for federal organizations starting back in 2010, but the weaknesses found in the SHA-1 algorithm has prompted NIST to restrict it’s use for all digital signature generation.

Digital signatures have two aspects: signature generation and signature verification. In January 2011 NIST issued Special Publication 800-131A titled "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths." Digital signature generation is addressed in Appendix B.2, Digital Signature Generation Using Asymmetric (Public) Keys and SHA-1. Here NIST states, "Some applications, such as signing a public key certificate, are very high risk and the use of SHA-1 in those applications should be avoided as much as possible. In NIST’s view, after 2013, the risk is unacceptable in all applications, and the use of SHA-1 when generating a digital signature is not allowed after that date."

Signature verification of already calculated hashes will still be allowed in what is termed a "legacy-use" period.

SSL uses X.509 certificates which are frequently seen with the Signature Algorithm attribute sha1WithRSAEncryption. As December 31, 2013 is fast approaching you may want to consider recreating these certificates with one of the newer SHA-2 algorithms such as SHA-256 or SHA-512. For example when creating certificate signing requests with OpenSSL try using "openssl req -new -sha256 etc...".

NIST has good reason to restrict the use of SHA-1 after 2013. Not only have experts found weaknesses in the SHA-1 algorithm through differential attacks, companies using SHA-1, such as LinkedIn, have already fallen prey to hackers. LinkedIn’s data breach this year could have likely been prevented if they had been using stronger hash algorithms with proper salting.

Is your company still using SHA-1 hash algorithms? Learn more about why you should move to SHA-2 or higher  in our podcast, “How LinkedIn Could Have Avoided a Data Breach” featuring security expert, Patrick Townsend.

The National Institute of Standards and Technology (NIST) announced the selection of the new Secure Hash Algorithm SHA-3 this week. The winning algorithm is Keccak submitted by the team of Guido Bertoni, Joan Daemen and Gilles Van Assche, and Michaël Peeters. This culminates five years of work by the NIST team and the work of many Cryptologists and security specialists around the world. We owe a huge debt of gratitude to everyone involved in this project. While we are hardly aware of how much we use and depend on the work produced by this community of academics and professionals, it is hard to overestimate how much each of us benefits from this work.

Do I need to do anything right now?

No. The SHA-2 family of hash algorithms is considered secure and there is no near-term concern about this family of secure hash algorithms. Here at Townsend Security, when we reach for a secure hash algorithm, we use SHA-256 from the SHA-2 family, and it is expected to be secure for many years to come.

HOWEVER, if you are using MD5 or SHA-1, it is time to upgrade to SHA-2 , or SHA-3 if you like.

Will this new algorithm change how we do message authentication?

I don’t think so. There is some new flexibility in respect to the length of the generated hash, but the use of SHA-3 is likely to be very similar to SHA-2. The advantage of SHA-3 is that it is not SHA-2. That is, if SHA-2 is found to be weak in some way, it is not likely that SHA-3 will be weak in the same way. Basically, SHA-3 will be used for the same purposes as SHA-2.

Will I need to use a salt with this hash method?

Yes, you would use a salt value with SHA-3 for the same reasons you would for SHA-2 – to avoid dictionary attacks that are often optimized with rainbow tables. Any time you have a small amount of data to hash (think credit card number, social security number, email address, and so forth), it is a good idea to use a salt value, and to take care to protect the salt from disclosure.

Is there any reason NOT to use SHA-3 now?

As Bruce Schneier points out in his book on “Cryptography Engineering”, there are lots of ways to get security software engineering wrong. I don’t worry about the underlying security proofs of the SHA-3 algorithm, but I do worry about bad security software engineering because I’ve seen so much of it. I am sure that NIST will have a validation program for SHA-3 (maybe it is already in place), and security vendors will bring their work through this process. I think there are good reasons to wait for the technology to mature before jumping into using SHA-3.

Pop quiz:

Does the name Joan Daemen ring a bell?

If you remembered his name from the Advanced Encryption Standard (AES) competition some years ago, kudos to you! Joan Daemen and Vincent Rijmen submitted the work that became this important symmetric encryption standard.

Happy Halloween!

Patrick

The loss of passwords by LinkedIn, eHarmony, and Last.FM should be a wakeup call for CIOs, security auditors, and IT security professionals everywhere. Let’s take a look at what probably happened, what you can do, and why you need to look beyond passwords on your own systems.

One-way hashes are used in many places in your applications for data protection, data verification, and integrity checking. It is one of those fundamental building blocks of security. There are standards for hash algorithms and conscientious security professionals will be sure that a system uses industry standard hash methods such as those recommended by the National Institute of Standards and Technology (NIST). The Secure Hash Algorithm (SHA) is one of those standards and is readily available in a variety of open source and commercial applications (we have one). It is a common practice to save passwords as hashes rather than saving the password in the clear or encrypted. (You could, of course, protect passwords with encryption and good key management, but that is a discussion for another day).

LinkedIn was using SHA-1 for their password hash. So what went wrong?

First, SHA-1 is no longer recommended for use in security systems. It has been replaced by a new family of stronger and more secure SHA methods with names like SHA-256, SHA-512, and so forth. These newer hash methods provide better protection from the type of attack that LinkedIn experienced. We use SHA-256 or strong methods in all of our applications. So using an older, weaker algorithm that is no longer recommended was the first problem.

Second, it is considered a security best practice to use a Salt value with any data that you are protecting with a hash method. What is Salt? In the context of hashes a Salt value is just some additional data that you add to the sensitive data you want to protect (a password in this case) to make it harder for an attacker to use a brute force attack to recover information. LinkedIn was not using a Salt value with passwords, and more simple passwords were easily recovered. (More on Salt in a moment). The attackers easily recovered LinkedIn passwords.

LinkedIn has apparently taken some steps to better protect their passwords. Is it enough? Let’s look at what should be done. This will help you look at your own Web and IT systems and understand where you have weaknesses.

These are all common recommendations from the security community:

Recommendation 1 – Use industry standard, strong hash methods

You should be using SHA-256 or SHA-512 for this type of data protection.  Do not use weaker versions of the SHA hash method, and do not use older methods like MD5. Do not be swayed by arguments that hash methods consume too much CPU power – just ask LinkedIn if that is their concern right now!

Recommendation 2 – Use NIST certified hash software libraries

If you use a hash method to protect sensitive data, you should use a NIST-certified software library. Why? Because it is terribly easy to make mistakes in the software implementation of a SHA hash method.  NIST certification is not a guarantee, but in my mind it is a minimum requirement that you should expect. I find it curious that most people would not consider buying a used car without a CARFAX report, but completely ignore NIST certification when deploying hash software to protect sensitive data. A lot more is at stake, and you don’t even have to pay to verify certification!

Recommendation 3 – Always use Salt with your hash

Always use a Salt value when creating a hash of sensitive data. This is particularly important if the sensitive data is short like a password, social security number, or credit card. A Salt value can make it much more difficult to attack the hashed value and recover the original data.

Recommendation 4 – Use a strong Salt value

Never use a weak Salt value when creating a hash. For example, don’t use a birth date, name, or other information that might be easy to guess, or discover from other sources (attackers are great data aggregators!). I recommend using a random number generated by a cryptographically secure software library or HSM. It should be at least 4 bytes in length, and preferably 8 bytes or longer.

Recommendation 5 – Protect the Salt value

Protect the Salt value as you would any sensitive cryptographic material. Never store the Salt in the clear on the same system with the sensitive data.  For the Salt value, consider using a strong encryption key stored on a key management system that is itself NIST certified to the FIPS 140-2 standard.

Are your systems at risk?

You are probably using hash methods in many places in your own applications. Here are some thoughts on where you can start looking to uncover potential problems with hash implementations:

• Passwords (obviously)
• Encryption key management
• System logs
• Tokenization solutions
• VPNs
• Web and web service applications
• Messaging and IPC mechanisms

Hopefully this will give you some ideas on what questions to ask, what to look for, and where to look for possible problems on your own systems. You don’t want to be the next LinkedIn, eHarmony, or Last.FM. They are not having fun right now! 

Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about my take on this breach and ways you can keep this from happening to your organization.

Patrick

The recent news of SAIC being dinged for not protecting US military TRICARE medical information with standard AES encryption and suffering a data loss is interesting. While the details are still thin, it appears that the data was encrypted, but not with a standard AES encryption method. The HITECH Act proposed data security rules make specific reference to AES and other NIST standards.

We don’t know which encryption method was used to protect the data. It could have been a home grown method of encryption, or it may have been a widely accepted encryption method that was just not a part of NIST standards. But it apparently doesn’t matter. If you are not using a NIST standard method of encryption, you are in violation of the compliance requirements.

I think it is going to take some time for the implications of this to settle in. Here are some rather unorganized thoughts:

Over the last two years I’ve seen at least FOUR instances of vendor “AES” encryption solutions that actually weren’t AES encryption. In one case, a point-of-sale vendor implemented an AES encryption library with a 256-bit AES block size. The AES standard (FIPS-197) only allows the use of a 128-bit block size.  The company running this software had no idea that they weren’t actually running an industry standard method of encryption.

In another case a customer was running AES encryption with a non-approved mode of encryption. The underlying encryption library was AES, but the mode was not a NIST-approved mode of operation. This was a distinction lost on the company running this “AES” solution. But it seems likely to me that they were out of compliance and at risk in the same way SAIC was. This company is going to have to rip out the current solution and replace it with something that is actually compliant. That seems like such a waste of time and resources.

In one of these cases the software was provided by a “security” vendor. This vendor sells encryption and key management software specifically to meet encryption compliance regulations. That’s very sad.

With the best of intentions and with deep knowledge of encryption protocols, you can still make mistakes when developing an encryption solution. It is hard to get this right. And weak vendors without the commitment and passion to get it right represent a risk to everyone. So, if you are a vendor of encryption solutions, what do you do to insure that you are getting things right? You learn to not trust yourself so much, you invest in independent review of your solutions, and you invest in independent certification. Today we would never release an encryption product without subjecting it to NIST certification and independent review.

If you are a company facing an encryption project, how will you select a security vendor for your encryption libraries and encryption key management solution? How will you know that their AES encryption is really based on the NIST standard? Are you ready to trust the claims of a sales person? I wouldn’t, and I don’t think you should, either. If a security vendor can’t show you a formal NIST AES Validation certificate, or a FIPS-140-2 certification, you should run for the nearest exit. You just have way too much to lose.

If you think that the HITECH Act is unique in its reference to NIST standards, have a look at the proposed Federal Privacy Law (Senate Bill 1151) that passed out of the Senate Judiciary committee last week. It is likely to empower the FTC to propose standards for encryption and encryption key management, and the FTC is likely to look to NIST for these standards.

The writing is on the wall, or rather, it’s on the Internet at www.nist.gov.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Patrick

First, like a proper workout, there are two parts.  There is the encryption process and the often after-thought of key management.  You need both for a successful and compliant data privacy solution.  This is much the same as hitting the gym.  You need to do your weights as well as run on the treadmill for a comprehensive workout.  Just because you are encrypting, doesn’t mean that you are doing it correctly, or will pass any sort of audit for that matter.

Next comes the personal trainer, or in the case of data privacy, regulatory compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC, etc). Privacy regulations show you proper form.  They spell out exactly what you need to be doing to meet compliance regulations.  Check out the concepts in PCI DSS Section 3 for encryption and key management requirements.  Not only are privacy regulations helpful for providing best practices, but also in most cases apply directly to your business (PCI DSS, state privacy laws, etc.). 

Sometimes difficult to meet, compliance regulations are a good thing.  They are what protect your and my personal information.  One good way to ensure you are going down the right path is to use NIST-certified AES encryption and FIPS 140-certified encryption key management.  These certifications assure that the solution is proven and validated by a third-party.  It is a very expensive and time intensive process, but ultimately assures the encryption and key management solutions can meet the most stringent privacy regulations.  Only the very best encryption and key management offerings can do this.

Why make your workout harder than it needs to be?  Start your workout right from the beginning and you won’t be throwing your back out later (did you know an average data loss costs a company over $200 per record?).  Believe it or not, there are still some “encryption” solutions that aren’t NIST-certified.  Some companies say “we meet the standards of NIST and FIPS regulations”, but have nothing to prove it.  If you dig a little deeper you’ll see NIST has no record of them.  It’s kind of like trusting an infomercial that says all you need to do is use their contraption for three minutes a day and you’ll look like a body-builder.  I’d rather spend my time and efforts sticking to a proven method for getting in shape.

For more information on encryption and key management, download our white paper titled “AES Encryption and Related Concepts.”

I believe that every individual or company that attempts to bring encryption products to market experiences an “Aha” moment. This is the moment when you realize how very difficult it is to get encryption right, and how many ways there are to get it wrong.

It’s not just that encryption is complicated (it is; to a non-mathematician the algorithms can be mind-boggling). It’s that there are so many aspects to doing an encryption implementation correctly that the likelihood of errors is high even for the best-intentioned and most knowledgeable developers. This “Aha” moment can be dramatic. It happens when you see all of your limitations clearly and you know that you are facing a crucial challenge.

However, what a person or company does after this “aha” moment says everything about their character and the quality of the products they bring to market.

When I had this “Aha” moment years ago, I realized that our company had to radically change how we approached the development of our encryption and key management products. I knew that we had to step up to much higher standards, and change how we looked at our own products. But where does one go to figure out how to do encryption right? Fortunately, our company had several good enterprise customers who helped point the way. Enterprise security architects directed us to the National Institute of Standards and Technology (NIST) web site and the FIPS-140 certification process. The NIST and FIPS-140 certification outline the proper standards and best practices for encryption, decryption, key management, and logging.  So began the complete transformation in how we bring Townsend Security encryption products to market.

It wasn’t long, however, before the “Aha” moment was followed by an “Oh no” moment.

It quickly became clear that there was a large body of published guidance on the standards and best practices for encryption and key management. This stuff would fill a small library. And it was intense reading. This was not “Dick and Jane” beginning level stuff. It assumed that you started at a pretty advanced point in your knowledge of encryption and cryptographic module implementation. Not only are there published standards, but there are well-defined test and certification protocols.  And these tests were not going to be easy to pass. These tests are only conducted by a small number of certified labs (See NVLAP), the tests are detailed, complex, and designed to detect even the most minute errors that could cause encryption algorithms to fail.  Certification also means that you must undergo a stringent review of the encryption source code and your development practices.

This was the “Oh no” moment. This process was going to hurt.  It was going to be expensive, time consuming, and mentally taxing. And (at least initially) it was going to slow down our release schedule and increase our time to market.  There was also the concern that some competitors would rush to market faster with whiz-bang features that impressed customers in the demonstration process, but were of less importance to encrypting data.

This was going to be a huge undertaking.  I huddled with our development team. I huddled with our sales and marketing team. I took a long walk.

It was clear to me that this was a decision that would define who Townsend Security would be as a company, and it would illuminate how we really feel about taking care of our customers.  Were we really committed to doing security right and providing complete solutions to our customers?  Or were we willing to scrape along the bottom with inferior products that could be sold to less sophisticated customers?

Well, you already know how this came out. In the end I could come to no other conclusion.  We would either do the right thing, or get out of the security market altogether. We’re still in, so you know that we made that commitment and investment in NIST certification of our correctly implemented encryption solutions. We did learn a lot about encryption development processes and best practices. And I must say our products are so much better for it.

As you know, we made a substantial investment in the certification effort (we still do), and we do have some competitors, especially in the IBM System i (AS/400) marketplace, who claim to have jumped ahead of us.  But I know how dramatically our certification efforts improve our products, and I know how much better off our customers are because of it. Customers who have a NIST certified solution will be protected from harsh regulations, those who put their trust in non-certified solutions will find themselves at the mercy of ever evolving regulating standards.  As these compliance regulations evolve and incorporate standards and independent assessment in their guidelines, our customers will benefit from our efforts. And as the attacks on our protected data get ever more sophisticated, we will see poorly crafted encryption and key management products easily broken with heartbreaking losses for the companies involved.

So, I am a converted believer in the independent certification process.  No one believes that independent NIST certification is a guarantee of perfect security. But no one who has been paying attention believes anymore that a security product should be trusted without it.  We believe the encryption and key management you trust to protect your entire Enterprise database should be equally (if not more stringently) proven and validated.  Click here download a free 30-day evaluation of our NIST-certified AES encryption - available for all Enterprise platforms (Windows, UNIX, Linux, IBM i, IBM z).

Patrick