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
It’s been all over the news, that Albert Gonzalez recently pled guilty to masterminding a large number of highly visible data breaches at 7-Eleven, Hannaford, and Heartland Payment Systems. Now that Gonzalez’ modus-operandi is public knowledge, I only wonder how quickly the other bad guys will copy and improve upon his methods. It’s clear that to stop the next Albert Gonzalez, it’s important to take a closer look at how he did what he did.
The attack on 7-Eleven was interesting in that it resulted in compromised debit card PIN security. Hmmm, you might say, “Everyone knows that debit card PIN codes are encrypted. How could they be compromised?” The truth is surprising to some, but was well known to Gonzalez, and provided the perfect weak point to exploit.
It’s understood that PIN codes ARE always protected by encryption. The encryption occurs right in the payment terminal. The transaction is then encrypted all the way to the bank, right? Well, not always. What many people don’t realize is that a retail merchant may use “zone encryption” to decrypt the PIN code on a central corporate server, and then re-encrypt the PIN before sending it to the bank or payment processor. This decrypt and then re-encrypt step is often used to gain a certain amount of independence from the processing bank (more on why this is done below).
To decrypt and re-encrypt the PIN transaction you need a Hardware Security Module (HSM) that is designed for this purpose. There are a few vendors of these systems in the market. They all work about the same way. You load your payment terminal encryption keys in the HSM, along with the bank’s encryption keys. Then, as the transaction passes through your central server, you hand the encrypted PIN code to the HSM and ask it to decrypt the PIN and re-encrypt it with the bank’s keys. Pretty simple, really.
So how did Gonzalez and his gang gain entry in the first place? All the break-ins appear to have started as SQL injection attacks on externally facing company web sites. Once a web server was compromised, Gonzalez gained entry to internal servers. SQL injection attacks are a well known form of attack and the usual goal is to gain access to a server with a high level of permission. Once a hacker has access to an internal server, further access to other internal servers usually follows.
As I’ve mentioned before, hackers are getting a lot smarter, more determined, and more focused on striking where the money is. I believe the industry should prepare for attacks on key storage and key server systems next. HSM’s are a type of key server. And that’s exactly what happened in this breach. The hackers exploited a weakness in how PIN encryption takes place on HSMs to discover the encryption keys. They were then able to get the PIN codes for debit cards. Once they had card numbers and PIN codes it was easy to manufacture debit cards using standard magnetic swipe cards and a relatively cheap mag-stripe writer.
It is not trivial to attack an HSM. You have to know a lot about PIN encryption formats, how HSM interfaces work, and how there may be weaknesses between PIN encryption schemes. But these attackers were really smart. They understood these things as only a security professional would. And they used this knowledge against the HSM.
What lessons can we take from this? Here are just a few that come to mind:
• Weak key management is no key management. If attackers are smart enough to exploit an obscure API weakness in a commercial HSM, they are smart enough to defeat your home grown key management system.
• Storing encryption keys on the same system with protected data is just plain wrong. Always use an external key server for key storage and retrieval.
• Key management systems should produce logs of invalid access attempts. You should collect and monitor these with your log management and alerting software.
• It’s time to review your encryption and key management strategy. Start migrating to NIST certified solutions, and get educated on encryption and key management best practices.
For those of you who want to know a bit more about “zone encryption,” it might be interesting to note that many large retailers and payment processors use this strategy to get some independence from their processing bank. If the PIN encryption keys are only stored on the payment terminal and at the bank, retailers and processors can’t change banks without changing out all of their payment terminals. If the retailer has lots of stores, this can be really expensive. Zone encryption allows them to de-link that connection to the bank, giving them some leverage to keep bank fees low, and making it easier to change banks if they want to. The use of zone encryption is fairly common and is not going away. However, since it’s now clear that data thieves are targeting this practice, it’s more important than ever to make sure you’re using strong and reliable encryption key management.
On that note, I’m proud of our technical team for having the foresight two years ago to anticipate attacks on key management systems. We went to work on a new appliance-based key management solution, which bore fruit in 2009. We released our new Alliance Key Manager product to the partner channel mid-year and will release it to the end customer channel this quarter. I’m sure I’ll be talking to more of you about this in the coming months.
I wish you a safe and secure New Year.
Patrick
We believe (and customers agree) that our people are a big part of what makes PTSS an exceptional company. This month, we shine our spotlight on Director of Support, Jeff Atwood. In his seven years with PTSS, Jeff has worn many hats, filling the role of graphic designer, webmaster, and marketing manager. Jeff has now been a valued member of the customer support team for six years. He says, “I’ve always enjoyed helping to solve people’s problems and love educating customers. But what’s really kept me interested over the years is the constant challenge of learning new technologies and helping people put that technology to use.”
Jeff has lived in and traveled to many foreign countries, mostly in Latin America, and has a working knowledge of the Spanish language. Besides his impressive technical knowledge, Jeff’s language skills have made him a valued part of the support team. As the PTSS customer base continues to grow around the world, Jeff looks forward to expanding customer support to increase our high-level of service across more time zones. He also hopes to get more feedback from customers so we can better understand and fulfill their support needs.
Away from work, Jeff enjoys spending time with his family. Several years ago, he and his wife adopted their son Jackson from China, then 5 months later became the proud parents of daughter Lilly Penelope. Jeff also enjoys camping, scuba diving, boating, and volunteering with his local schools.
We are a creative and inventive species! As I look back over the last year of this decade, it amazes me how many new technologies and services have been introduced despite the challenging economic times. We’ve seen new smart phones, tablets, book readers (galore), cloud computing services, web services, and more. Many of these wondrous technologies have the amazing ability to entertain as well as educate. What a divine gift we’ve received in this ability to create new ideas and new tools!
These innovations inspire us to help PTSS customers protect their data carried on these new technologies. This year we’ve brought forward new encryption, key management, tokenization, and systems management products. These include new PGP encryption offerings on the IBM System i and IBM System z platforms, a new key management solution for all platforms, a data tokenization product to complement encryption, and a wide variety of enhancements and features in our existing products. It has been an exciting year for us as a company.
Of course, to keep up with these innovations we make a large investment in research and development. The PTSS development team is a much larger percentage of our company than you would find at the typical software company. I believe that this is a necessary fact of life for a data security products company. To keep our customers safe, we have to keep up with a constant stream of technological innovations, while always working to stay a step ahead of the cyber-criminals trying to break into all this shiny new technology.
I’m especially grateful for the uptake of our security technologies in the ISV and embedded systems market. Our products are increasingly being incorporated into third-party solutions where they quietly help customers protect sensitive information. I’m proud of our relationship with Quantum, the leading provider of managed tape backup solutions; as well as partnership with companies like PGP Corp. You will be hearing more about our partner successes in the coming months.
A large part of my job is to try to look into the future and anticipate the coming needs in data security. Some time ago we saw the emergence of NIST standards as a part of compliance regulations. We did the hard work early on, and now have our encryption solutions NIST certified. We are currently in FIPS-140 certification for our new key management solution, and I am confident that we will complete this process in 2010. I continue to believe strongly that NIST certification will be important to our customers in the future. I believe that our current and future customers will benefit from this effort.
I hope you all have a good holiday and I wish you a happy new year!
Patrick
When most people hear the name Patrick Townsend Security Solutions, they think of company founder and CTO Patrick Townsend. But while Patrick remains a driving force behind the company, we also have a rich pool of talented people who have made significant contributions to our success. One such person who has been with us since our earliest days is Lead Developer Paul Ohmart. Paul has worked closely with Patrick for nearly half of his 30 years in programming, and has had a hand in developing many of the products on our roster.
“Paul’s fingerprints are on many of our products.” Patrick agreed, “He’s been a major collaborator in overall product and feature development, and his contributions have been crucial to the success of those products.”
When PTSS first recognized the need for certified AES encryption specifically for the IBM mid-range and mainframe computers, Paul combined his expertise and thirst for knowledge to soak up everything he could find on encryption technologies. The resulting Alliance AES encryption and key management product lines have become cornerstones of the company.
More recently, Paul focused his talents on developing the key management technology Quantum, Corp now licenses for use in their Scalar Key Manager. Beginning in August of this year, all Quantum tape drives sold with encryption and key management capabilities contain the key management solution developed by Paul and his team. This same team is now putting the finishing touches on PTSS’ own Alliance Key Manager product. That technology is currently being NIST-certified, and will be released in early 2010.
Paul is not always chained to his computer keyboard however. He also takes guitar lessons, is learning to sail on the Puget Sound, and nurses a life-long addiction to the Japanese board game GO (igo).
When asked to sum up his work at PTSS, Paul said, “I enjoy the opportunity to exercise my creativity at PTSS. The Alliance Key Manager project in particular has provided the opportunity to bring together many of the experiences of my career while giving me a chance to delve deeper into the fascinating world of encryption.”
As we near year’s end, I realize that the biggest change in data protection for 2009 has nothing to do with technology. Instead, it involves a shift in attitude.
The old attitude: “We have to put up all of the barriers to secure our data. We’ll throw on new intrusion detection, firewall, web filter, data loss prevention appliances, and put all-hands on deck to protect the perimeter!”
The new attitude: “Despite our best efforts, data gets out. We need to protect it from abuse.”
I think this new attitude reflects the reality that the threats to data security are ever more sophisticated, and the number of loss points has increased exponentially. The bad guys are amazingly successful at installing malware inside our networks and hiding their presence.
Cyber crooks don’t want to get noticed, they want to steal as much data as they can before we find them.
To make the situation more difficult, we are awash in new technologies that magnify the potential for loss. Social networks, instant messaging, smarter phones, SaaS, cloud computing, and on and on. There is just no way a self-respecting IT security organization can keep up with the pace of change. Innovation is fun, but it sure isn’t easy to secure.
Due to this challenge we are slowly coming to the realization that we have to encrypt sensitive data everywhere it lives and travels. This means encrypting data on laptops and other portable devices, on the wire as we transmit data on internal and external networks, on our backup tapes, and in our databases where we permanently store data. We’ve been slow coming to this realization because encryption is one of the harder technologies to deploy. It takes more work and more resources (hardware and human) to do it, and there is really no magic bullet we can shoot at the problem. So we are starting the hard slog to get encryption deployed on our systems.
I’m not suggesting that everyone unplug their firewalls, web filters and DLP appliances and deploy encryption. These solutions all have their place and are important in the security eco system. But we simply can’t be secure without encryption to protect the data. Now before you get fired up to tell me “encryption is not a panacea,” I’ll head those comments off by saying “I know that.” You have to do a lot of things to minimize the threat of data loss. (Please reread the first sentence of this paragraph). I’m just saying that we’re not going to mitigate that threat without encryption as a part of the plan.
The bad guys are really smart – we have to give them that. I fully expect that we will see attacks on encryption and key management solutions. In fact, we’ve already seen attacks on weak encryption and bad key management techniques. So I am not naïve about encryption being immune from these types of attack. But encryption done right provides a big barrier to jump over. I personally think that we have to make the leap and get busy implementing strong encryption of our sensitive data.
As you start to work on encryption projects, here are a few things to think about:
- Performance is really important. Be sure to test the performance of your encryption solution on a large set of data. Badly performing encryption is one of the hardest problems to fix.
- Cross platform compatibility is crucial. If you encrypt on one platform, you don’t want to have to decrypt data in order to transfer it to another platform. That just opens another door for loss. Be aware that not all AES encryption is done the same way.
- NIST certification is important. Regulations and best practices recommend independently certified encryption and key management solutions, so procuring certified solutions can help position you for the future. NIST certification also answers the question about cross platform compatibility.
I know encryption is not easy to implement. That’s why PTSS focuses on doing encryption right and easing your way into what should now be an integral part of your overall data security plan.
Patrick
Tokenization has become a hot topic lately as Enterprise customers attempt to minimize their exposure to the loss of sensitive data. Tokenization is an alternative to encryption and one-way hashes for data protection. But I think it is time to dispel some of the myths about tokenization, and discuss where this technology can be helpful in minimizing your risk.
First, tokenizing data does NOT let you bypass PCI compliance requirements. If you are a Level 1 merchant (and Level 2 at the end of 2010), you will still have to perform an annual PCI audit by a qualified QSA auditor. If you are a Level 3 or Level 4 merchant, you will still need to complete the self-assessment and meet the requirements of PCI. In some cases tokenization can help minimize the impact of PCI compliance, but in most cases it is not going to provide a significant benefit. This same is true for HIPAA and state privacy regulations.
If you are using payment-network-assigned tokens as replacements for credit card numbers, you are going to benefit by a reduction in the need to encrypt the account number and related cardholder information. In this case, when you send a payment authorization to the payment network, the response contains a token that you can store for later use. When you settle the authorization, or when you make future authorizations for recurring payments, the token will be used instead of the original credit card number. You never store the original credit card number in your database. That reduces the work you need to do to protect sensitive information, but does not get you out of PCI compliance. Only a small number of payment networks now support tokenization, so it is unlikely this is going to help you in the near term.
If you create the token on your local server, you will probably get very little relief from PCI, HIPAA, and other privacy regulations. If the token allows recovery of the original data, you have all of the normal obligations to protect the data. And, your risk may actually increase if you store the tokens for multiple applications in the same database, or if you store those tokens on the same server as the production data. For example, let’s say you store credit card numbers in the token database along with employee social security numbers, and customer account numbers for electronic funds transfer. If you have a compromise of the token database, you now have an exposure to multiple compliance regulations. Unauthorized access to the token database means you have to assume you’ve lost sensitive data for several applications.
There is one area where tokenization can provide an immediate and significant benefit – minimizing exposure in test, QA, and user acceptance environments. Many companies use multiple test and QA environments as they migrate system changes into production. To do this, you need realistic data in your test and QA databases. It is common to take snapshots of production data and use this for testing. However, this practice exposes sensitive data to a much larger group of people. Using tokenization, to replace sensitive data with bogus data, greatly reduces the risk of exposure.
The main problem I see with tokenization is that it lacks a proper definition by any standards group. It was heartening to see Visa issue some guidelines on best practices for encryption and tokenization just this month. While these are not yet formal standards, they do represent a good framework at which to look at tokenization. I was satisfied to see that our products match up with these best practices.
As many of you already know, we are just now releasing version 2 of our tokenization support. It provides an implementation of tokenization that will help you protect test and QA environments, allows separation of tokens from the production database, provides a common token database for Windows, Linux, UNIX, and System i applications, and meets proper standards for encryption and token creation. And of course it matches the Visa Best Practices guidelines for creating tokens so that you are prepared for future developments in this regulatory environment.
I hope this helps you cut through the haze of bogus information floating around about tokenization. As always, if you need more information about encryption, tokenization, or data security, you can get answers on our website or contact me directly.
Patrick
In the last few months we’ve seen a lot of discussion about data loss due to deliberate insider threats. Despite some very visible cases of infiltration by malicious insiders, recently IDC published a research report showing that more than half (52 percent) of insider data losses are accidental. This report challenges us to think differently about how to protect our sensitive data.
Just to keep things in perspective, protecting sensitive data is important to the survival of our businesses. It’s been estimated that data breaches can result in about an 8 percent loss in business and customers, combined with the cost of about $200 per record in remediation and legal costs. In today’s economy that is a hit no business can afford. So how do we protect against accidental data loss?
Most of us are putting our attention toward protecting our data from malicious attacks. We are deploying Data Loss Protection (DLP) products, doing better background checks, and deploying ever more sophisticated firewalls and intrusion detection systems (IDS). This study would indicate that we should look much more carefully at the routine activities of our employees and contractors.
The IDC study indicated that negligence, unintentional malware exposure from web browsing, and excessive privileges accounted for the top three accidental insider data losses. And it is not just full time employees who are responsible – contractors, temporary employees, and out-sourcing agencies are also big contributors to the problem. Good people inadvertently do bad things. But regardless of the intent, the impact on the company is the same. As cartoon character Pogo once said “We have met the enemy and he is us.”
How can we protect from this threat?
The IDC study concludes that there is no single technology that can mitigate this threat. We need to use a combination of encryption, monitoring, data loss protection, and education to minimize the potential for loss. A big part of the change is one of attitude – we need to realize that our trusted employees can and simply do make mistakes.
This propensity for error makes it all the more important to protect information in our core database systems. That’s why we were one of the first companies to incorporate access controls and system logging inside our encryption products. From the beginning, we felt it was important to limit who could and could not decrypt sensitive information, and to be able to track that activity.
As long as humans are part of the equation, we have to take encryption of data at rest and in motion very seriously. We can’t yet stop accidents from happening, but using strong encryption and proper key management can ensure that when accidents do occur, they aren’t fatal to your Enterprise.
Just last week a group of cryptographers announced a practical attack on some versions of 256-bit AES encryption. This announcement initially created quite a stir in the cryptography community, before reality set in and the scope of the vulnerability was defined. The attack is quite sophisticated and represents a major step toward breaking AES. While you might think that 256-bit AES encryption is the strongest encryption you can deploy because it has the largest key, in fact, key size is only one aspect of the strength and reliability of encryption. And in this case a weakness in key handling at the 256-bit level exposed a weakness in some, but not all, versions of AES encryption.
At this point you are probably asking yourself – am I at risk?
The answer is – that depends. Is your encryption solution NIST certified as Patrick Townsend Security Solutions are, or is it an open source or proprietary solution that some programmer hacked together on their own?
The recent attack that everyone’s talking about used 256-bit AES encryption that implements 10 or less rounds (repetitive processing that transforms the input using the encryption key) during the encryption process, combined with a set of related encryption keys and known plaintext values. The good news is that NIST defines the minimum number of rounds for standard 256-bit AES encryption at 14. There is no known practical attack on 256-bit AES encryption that implements 14 rounds.
If you are using a NIST-certified AES encryption solution you can now relax (our Alliance AES encryption solutions are NIST certified on all platforms).
If you are NOT using a NIST certified solution, or if you don’t know if your solution is NIST certified, you have some work to do. First, rather than ask your vendor if they are NIST certified, you can determine if your vendor has completed NIST certification by looking at the NIST AES Validation list. A NIST AES validation is specific to the operating system and hardware platform. Be sure you find a match with your implementation. If your vendor is not on the list it’s time to pick up the phone, call your encryption vendor, and ask some questions:
• Does your implementation use 256-bit AES encryption?
• How many rounds are used, and can the number of rounds be independently verified ?
• Where did you get your implementation of AES? Which Open Source version did the developer start with?
• Is the solution NIST compliant? Can the vendor prove it? If it is not NIST certified, why not? Do they have a plan to get their solution certified?
• Can the vendor replicate the published NIST encryption results to validate that the code is working correctly?
You should get some clear answers to these questions. If your vendor experiences one of those “deer in the headlights” moments, or if the answers are not clear and simple, you may have a vulnerable version of an encryption solution on your hands. Your vendor might say something like “Well, it’s an implementation of Rijndael, so it’s Okay”. This is why independent laboratory certification from NIST is important. Some older versions of Rijndael used a smaller number of rounds, and less talented encryption programmers may not even understand what the difference is.
NIST certification is not an absolute guarantee that a security vendor has done encryption right. Nor is it a guarantee that there won’t eventually be a weakness in the encryption algorithm. But NIST does represent the very best in encryption standards and guarantees that your vendor has had some independent review of its encryption solution. Doing encryption right is important not only to guarantee that your solution is less vulnerable to attack, but also to give you the peace of mind that your data can be decrypted by you when you need it.
While this published attack on 256-bit AES will probably not pose a significant risk to your encryption strategy, it will serve as a wake-up call to many organizations that it is time to get serious about encryption vendors. Any serious vendor of encryption will take the minimum step of completing NIST certification. We all think it is a good idea for teenagers to have a driver’s license, security vendors should get NIST certified, too.
Bruce Schneier has a really good description of the attack and it is well worth reading. I really like Bruce’s view on security in general. He writes well on a wide variety of security topics and brings a nuanced view to the subject. You can sign up to get his email newsletter on his web site.
One last thought: the cryptographers who found this weakness were not up to anything bad. The study of encryption ciphers and the attempt to compromise them (called cryptanalysis) is an important part of keeping encryption secure. You REALLY should worry about using encryption that is home-grown, or out of the mainstream, because the only ones trying to find the weakness are the bad guys. And they are not going to tell you if and when they break your encryption. They are going to exploit it as much as possible and your business will suffer. Don’t wait for that to happen. Realize that the right time to take a good hard look at your encryption solution vendor is now.
I’ve known John Earl for a number of years and have always been impressed with his commitment to customers, his sense of business ethics, and his grasp of technology. John is an expert in security and has been an important figure in the IBM i community for a number of years. He understands the demands and challenges that Enterprise IT leaders face on a daily basis, and I am really glad to have him on board as the new CEO and President of Patrick Townsend Security Solutions.
John shares my commitment to keeping us independent and focusing on providing the best products available for encryption and key management. And I truly believe he is the perfect fit to help further our leadership in the Enterprise data security space.
With John assuming many of the duties that used to consume my time, I was recently able to move over to the position of CTO. This allows me most immediately to focus on the launch of our new Alliance Key Manager product. The key manager has already been successful in the partner space, and it will soon be ready for general release. We also have a number of new solutions in the pipeline that leverage our encryption and key management solutions, and my new position will allow me to focus the launch of those applications, as well.
I’m confident that Patrick Townsend Security Solutions still has its best days ahead. And John will contribute mightily to our successful future.