August 2016 | SafeLogic

Archive for August, 2016

30 Aug 2016

Still Not Validated

McLovinAES 256 is a fantastic cryptographic algorithm. I highly recommend it. Be aware, however, that deploying an algorithm that is approved for use within a FIPS 140-2 validated crypto module is NOT the same as holding a validation. Likewise, just because you’re over 16 years old and know how to operate a vehicle does NOT mean that you have a driver’s license. You may be eligible, but there are steps that must be taken to prove that you meet all of the requirements before you are issued that certificate.

If you get pulled over on the freeway, you had better produce a valid and current driver’s license. (No, McLovin, a real license.) In technology, you had better be able to produce a valid and current listing on the NIST website, showing completion of the Cryptographic Module Validation Program (CMVP) and a confirmed FIPS 140-2 validation.

In order to do so, you must use take your implementation of AES 256 (or another approved algorithm) and undergo thorough testing with the CAVP (NIST’s Cryptographic Algorithm Validation Program) as a prerequisite before your module can even enter the CMVP queue. Once that is complete, then the entire module can be tested to meet the FIPS 140-2 benchmark. Without the independent third party laboratory, without NIST involvement and without a posted validation, you do NOT have FIPS 140-2 validated encryption, you’re NOT eligible for federal procurement, and you’re NOT in compliance for HITECH Safe Harbor in healthcare.

If you are shopping for a solution and need FIPS 140-2, you need it to be validated and posted on the NIST website. Don’t be fooled by phrases like “FIPS compliant algorithms” or “conforming to FIPS standards”. Either it has been validated or it has not. Next time, we will tackle exactly what a FIPS 140-2 validation looks like and what it means, explaining each piece of the certificate listings publicly posted by NIST. Until then, enjoy a quick laugh about the difference between eligibility and certification.

[Click to enlarge.]In the Car



24 Aug 2016

How does the SWEET32 Issue (CVE-2016-2183) affect SafeLogic’s FIPS Modules?

Executive Summary:

SWEET32 issueA newly demonstrated attack, SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN, shows that a network attacker monitoring an HTTPS session secured by Triple-DES can recover sensitive information. The attack was performed in a lab setting in less than two days by capturing 785 GB of traffic over a single HTTPS connection.

Sounds scary at first.

The good news: No action is required by SafeLogic customers for the SWEET32 issue.


My FIPS 140-2 Module is not Broken?

Correct. Triple-DES [1] is a FIPS Approved algorithm and Triple-DES is expected to remain a FIPS Approved algorithm for the foreseeable future. Triple-DES uses 64-bit block sizes which makes it vulnerable to this attack. Cryptographers have long been aware of this type of vulnerability in ciphers designed with small block sizes.

The AES symmetric cipher (also a FIPS Approved algorithm) is not vulnerable to this attack.

[1] Two-key Triple-DES may only be used for decryption purposes in the FIPS mode of operation. Three-key Triple-DES may be used for encryption and decryption purposes in the FIPS mode of operation.

What Might NIST Do?

Since a considerable amount of ciphertext needs to be captured to make this attack possible, this is a low security concern for nearly every use of TLS. We anticipate that CMVP (NIST/CSE) may publish future guidance limiting the amount of plaintext that is encrypted using a single Triple-DES key, but we do not expect the CMVP to remove Triple-DES from the list of FIPS Approved algorithms due to this reported attack.


Should I Turn Off Triple-DES to be Safe?

That depends on your company’s security policy for addressing vulnerabilities. The SWEET32 issue does not make Triple-DES itself any less secure than it was yesterday and the method of attack is not new. You may need to continue supporting Triple-DES in order to allow TLS connections that are not able to negotiate use of the AES cipher. (Note that good security practices always negotiate AES at a higher priority than Triple-DES). In short, there is no need to turn off the use of Triple-DES in your application.


What If I Still Have Questions?

Please contact me. I am happy to be a resource to you.


18 Aug 2016

Encryption Concerns in the UK

This is a guest post from Amazing Support’s David Share as a special contribution to SafeLogic.

BlogFooter_Guest_DavidShareIn the early days of 2015, the British Prime Minister at the time, David Cameron, put forth an idea to ban all forms of encryption in the United Kingdom (UK) dealing with software and especially embedded in messaging applications. This proposal to ban encryption followed Paris’ Charlie Hebdo massacre, in which the attackers were thought to have been communicating with each other using apps similar to WhatsApp and iMessage. Were this ban to be realized, a backdoor would have to be created into any and all apps, whether web or mobile-based, that utilise end-to-end encryption.

Encryption has become a battleground as of late. Government bodies and those who fear that apps are being utilised for the propagation of terrorism seem to be firmly entrenched of the idea of creating backdoors in these apps. Technology companies, like Apple, and those who are trying to preserve what they perceive as the last vestiges of civil rights and privacies, are fighting to maintain encryption’s independence. Needless to say, both sides have their pros and cons.

Creating a backdoor, according to proponents like Cameron and current British Prime Minister Theresa May, would ensure that law enforcement and government agencies are able to monitor and act upon those that would cause harm to the UK. When using the Charlie Hebdo massacre as an example of how a ban on encryption could have helped, it does make sense.

However, tech companies and cryptography experts fear that the creation of a backdoor does not ensure that it could only be used by the “good guys”. To them, a backdoor is a legitimate vulnerability that could be equally exploited by foreign spies and corrupt police, among others. Businesses are concerned that it may portend the end of ecommerce as we currently know it, since almost all credit card transactions online are done through encrypted channels. If that encryption had a backdoor, it may create a sense of distrust among the consumer base and scare off business. Finally, there is the matter of privacy. If the encryption walls did fall by government command, then users are left terribly exposed and would have to endlessly worry if what they say online can be misconstrued as dangerous or worse, an act of terror.

UK Prime Minister Theresa May

UK Prime Minister Theresa May

The proposal has been legitimised and is known as the Investigatory Powers Bill (IPB) under Theresa May’s leadership. According to May, the bill does not state that tech companies are forced to create backdoors in their encryptions. However, it does require companies to provide decrypted messages upon the presentation of a warrant. This is a problem in and of itself, as the messages from apps that utilise end-to-end encryption cannot be accessed by anyone without a proper password or code, and that includes the software publisher. So to comply with IPB and present a decrypted message, some sort of backdoor will be needed. Through the use of sly wording, May and the IPB is effectively forcing tech companies to create backdoors afterall, lest they face a potential ban from operating within the confines of the UK.

Already known as the Snooper’s Charter, the IPB will test the limits to which tech companies and citizens are willing to relinquish a portion of their privacy. If the IPB ever becomes law, the government or any law enforcement agency must simply find cause to issue a warrant to gain access to any citizen’s message history. May and her supporters insist that they will only do this to people who may pose a risk to the safety of the nation, but who is deemed to be a threat can take on many meanings. The opponents of the IPB are afraid that this could and would lead to breaches in privacy laws, even going so far as to say that it would go against portions of the European Convention on Human Rights. Those challenging the bill are questioning Britons about whether they want to join the ranks of countries such as China and Russia, which closely monitor and even dictate what sites can be browsed, what data can be accessed and what messages can be sent.

It seems that May and the current government are selling the IPB under the guise of improving national security. However, they have failed to answer opponents’ concerns about the negative effects of the bill – the potential invasion of privacy and the creation of a new vector of attack for malicious hackers. May says that the bill does not infringe on the rights and privacies of the citizens but experts on the matter believe otherwise. More frighteningly, May and her party have yet to come up with a rational solution to the security problems that the creation of a backdoor poses.

If Britons were to stand up and made their voices heard they should do it sooner rather than later. The bill has already made it to the House of Lords and passed its second reading, and is now headed to the committee stage on the 5th of September. As it is, and without strong opposition from within the House or the people, the IPB will almost surely be passed and become law.

2 Aug 2016

Why Should We Get Our Own FIPS Certificate?

Why Should We Get Our Own FIPS Certificate?After our big announcement with OpenSSL last week, we’ve had some interesting conversations with possible future SafeLogic clients. Several have asked pointed questions, like “Why should we get our own FIPS certificate, if OpenSSL will get one after all?” and “Why buy the cow when we can get the milk for free with open source?”

I love these questions. It tells me that our potential partners have a healthy dose of skepticism and really understand the need to extract value from their capital expenditures.

In a nutshell, the answer is: because your customers also have a healthy dose of skepticism and need to extract maximum value from their expenditures!

Let’s start at the beginning. Building early versions of your product with open source encryption, whether it’s OpenSSL or Bouncy Castle, is a smart move. Open source crypto provides functional, widely compatible, peer-reviewed cryptography and leaves your options open for future replacements. Locking into a proprietary module early in the development phase has proven to be problematic when it requires unique architecture. (RSA BSAFE is now defunct, of course.)

The problems begin when you leverage open source for FIPS 140-2. In order to properly deploy an open source FIPS module within conformance standards, you need to follow the exact recipe. That means having to follow the 221 page User Guide for the OpenSSL FIPS Object Module v2.0, for example. That’s a lot of work, only to be questioned by your own prospective customers. “Where is your FIPS certificate? Don’t you have one with your name on it?”

Luckily, that’s exactly what SafeLogic provides. You’re not dealing with a DIY effort with directions from the worst Ikea bookshelf you’ve ever built. You get strong technical support from the SafeLogic team, standing behind our CryptoComply modules. (No, we don’t just send you a massive PDF of directions.) And that elusive FIPS 140-2 certificate? RapidCert delivers it in just 8 weeks, explicitly displaying your company name and operating environments. “Just trust me” doesn’t belong in your salespeople’s vocabulary.

So when you’re selling to the federal government, financial institutions, healthcare providers, or other regulated industries, expect your customers to be skeptical of your open source usage. You also need to be cognizant of the competitive landscape. You do not want to be cutting off your nose to spite your face, saving a few bucks by skating on FIPS validation, only to lose deals to rivals carrying certificates. Invest in your product and win those head-to-head opportunities! We even have a Top 10 list of reasons to choose SafeLogic over open source.

The comic below is a humorous dramatization of a sales call going wrong, but your target customers (in the green cube) really just want confirmation that your company carries a FIPS 140-2 validation. No tricks, no technicalities, just a certificate on the NIST website. Real, valid, honest-to-goodness, easy to cross-reference and confirm.

Open source FIPS validations are important for the community to have. It’s a good starting point, and for some small companies it’s the best that they can access. Maybe it’s enough for you right now. But customers can’t nitpick if you have your own certificate, and that’s where SafeLogic knocks it out of the park. You won’t find an easier or faster way to add that FIPS 140-2 validation to your salespeople’s arsenal. We’ll be ready when you are.

[Click to enlarge.]Why Should We Get Our Own FIPS Certificate?