Industry News Archives | SafeLogic

All posts in Industry News

30 Mar 2017

SafeLogic Wins Encryption Trophy at 2017 Govies

SafeLogic won at The Govies 2017!Security Today magazine announced the 2017 winners in “The Govies,” the Government Security Awards competition, honoring outstanding government security products. SafeLogic was selected as the winner in the ‘Encryption’ category for our CryptoComply product, adding another trophy to our case!

“It always feels good to win an award,” said SafeLogic CEO Ray Potter. “Being selected as the winner for encryption in a government-specific competition is even better. It really validates (pun absolutely intended) our strategy for FIPS 140-2!”

1105 Media launched its government security awards program in 2009, although they weren’t known as The Govies until two years later. Starting this year and going forward, 1105 Media’s newly relaunched Security Today magazine (formerly Security Products) will administer the awards program. Winners were selected using criteria including Features, Innovation, User Friendliness, Interoperability, Quality, Design, Market Opportunity, and Impact in the Security Industry, Technical Advances, and Scalability.

“The Govies is an amazing product recognition program whereby companies in the security industry can highlight their technology and solutions that work flawlessly within the government vertical,” said Ralph C. Jensen, editor in chief of Security Today magazine and securitytoday.com. “We received 28% more entries this year, which also corresponds with the need to provide better security options not only at the federal level but also at the state and municipal level of government. I believe these products and solutions only prove that the government relies heavily on the technology advances in the private sector.”

Other selections include SafeLogic customers BlackBerry, chosen for BlackBerry UEM in the ‘Convergence and Integrated Software and Solutions’ category and BlackBerry AtHoc in the ‘Emergency Communication Systems’ category, and Securonix, chosen for SNYPR Security Analytics for Hadoop in the ‘Big Data Analytics’ category.

BlogFooterWalt3

 

23 Mar 2017

FedRAMP Kicks It Up a Notch

FedRAMPHave you been following the evolution of the FedRAMP program lately? They are proving to be as nimble as any other group in federal, and even better – they are putting an emphasis on transparency. Check out their blog Focus on FedRAMP for example. After we gave kudos to the CMVP for their recent renewed efforts, it wouldn’t feel right to forget the folks at FedRAMP.

Last month, FedRAMP rolled out an update to their 3PAO Requirements. 3PAOs, Third Party Assessment Organizations, play a huge role in the process, just like the testing labs certified by NVLAP, the National Voluntary Laboratory Accreditation Program, do for FIPS 140-2. For each certification procedure to move smoothly, the 3PAOs and FIPS labs must meet an ongoing standard of excellence. In this case, FedRAMP worked with A2LA, the American Association for Laboratory Accreditation, and determined that they “need to strengthen the 3PAO accreditation requirements to provide for greater 3PAO oversight to ensure that a FedRAMP Accredited 3PAO provides the highest quality, most technically accurate assessments for the Cloud Service Providers (CSPs) who participate in the FedRAMP Program.”

FedRAMP-RAR-768x806An even bigger step forward was taken when FedRAMP unveiled the FedRAMP Readiness Assessment Report (RAR) Template as part of their FedRAMP Accelerated Process initiative in the summer of 2016. Their primary goal was to give Cloud Service Providers a pre-audit tool to self-assess and prepare themselves for scrutiny. But even more importantly in my opinion, the RAR was created as a living document, intended to be updated as needed to shed light on areas that need further interpretation. (Pro tip – make sure that you download the latest version of the RAR when you are prepping and doing due diligence. 3PAOs must use the most current RAR template that is available on the FedRAMP website at the time of submission.) This has been a huge help for CSPs hoping to secure FedRAMP approval. We have had more than a few frantic phone calls from CSPs that were suddenly faced with a mandate for FIPS 140-2 validation and they didn’t have a strategy. This should assist folks plan ahead and develop a more comprehensive plan in advance.

Despite our efforts to raise awareness about the requirement for FIPS 140 in FedRAMP over the last few years, it had still been a subject of debate. So it’s great that FedRAMP has finally made it more explicit in the RAR. For example, Section 4. Capability Readiness, subsection 4.1 Federal Mandates, bluntly asks “Are FIPS 140-2 Validated or National Security Agency (NSA)-Approved cryptographic modules consistently used where cryptography is required?” This should be no surprise, of course. A federal program requiring the crypto to be federally approved. That makes more sense than many bureaucratic requirements, doesn’t it? More below about the NSA caveat.

Further, check out subsection 4.2.1. Approved Cryptographic Modules [SC-13]:

The 3PAO must ensure FIPS 140-2 Validated or NSA-Approved algorithms are used for all encryption modules. FIPS 140-2 Compliant is not sufficient. The 3PAO may add rows to the table if appropriate, but must not remove the original rows. The 3PAO must identify all non-compliant cryptographic modules in use.

Table 4-2. Cryptographic Modules

  Cryptographic Module Type FIPS 140-2 Validated? NSA Approved? Describe Any Alternative Implementation
(if applicable)
Describe Missing Elements or N/A Justification
Yes No Yes No    
1 Data at Rest [SC-28]
2 Transmission [SC-8 (1), SC-12, SC-12(2, 3) ]
3 Remote Access [AC-17 (2)]
4 Authentication [IA-5 (1), IA-7]
5 Digital Signatures/Hash [CM-5 (3)]

As you can see from the Cryptographic Module planning matrix above in Table 4.2, FedRAMP is taking extra care to highlight the need for a FIPS validated module. They clearly had more than a handful of conversations with CSPs trying to argue for the use of a selection of algorithms from the CAVP list as ‘good enough’ and wanted to nip that in the bud. In fact, those were their bolded terms, not mine! The distinction is very important and the clarification was clearly needed.

I almost forgot. Circling back for those of you eyeballing the ‘NSA Approved’ verbiage as a potential loophole to bypass FIPS 140, I have just two words: Good. Luck.

That ubiquitous AES-256 implementation that you’re hoping will satisfy this requirement, because, after all, it is an included component for NSA Suite B… yes, well, it’s also included in FIPS 140-2 and therefore governed by CMVP/CAVP. So if there’s no CAVP certificate, and it’s not implemented as part of a CMVP validated FIPS 140-2 cryptographic module… well, let’s just say that you already missed St. Patrick’s Day and you’re going to need a whole truckload of four-leaf clovers for that to pass muster.

FedRAMP is taking great steps to take the mystery out of the process, and one of those major clarifications is the explicit reliance on the CMVP and FIPS 140-2 validation. If you’re reading this blog, you probably already know it, but nobody handles FIPS 140-2 requirements as quickly, easily, or effectively as SafeLogic. For more information, please explore our products and services at your leisure. They are designed to work in tandem and remove the hassle for your team. As always, contact us with any questions.

 

BlogFooterWalt3

7 Mar 2017

The CMVP Historical Validation List Is Here with a Vengeance

SunsetEditor’s note: This post was updated on March 14, 2017 to reflect a distinction that came to light in dialogue with CMVP – validations moved to the Historical List have not been revoked outright. The validation still exists, but are not for Federal Agencies to include in a new procurement. Agencies are recommended to conduct a risk determination on whether to continue using existing deployments that include modules on the Historical List.

Over a year ago, our blog featured posts about the RNG issue that was leading to certain FIPS 140-2 validations moving to the Historical List and the 5 year sunset policy that CMVP was adopting. [Geez, was that really more than a year ago? Crazy.]

Now the hammer has dropped, and the industry is seeing modules routinely relegated to the Historical List each month. The sunset policy created a waterfall in January 2017, and as of today, there are 1,914 modules on the Historical List, representing approximately 2/3rds of the total validations completed in the history of the CMVP.

Let me repeat that for emphasis. 1,914 modules.
Approximately 2/3rds of all modules ever validated by NIST to meet the FIPS 140 standard are no longer on the active validation list.

This includes some modules that were updated in 2016, and a few were even just revised in 2017! Many of these are hardware, so they are often more static and harder to update, but certainly not all. Check out the entire Historical Validation List for yourself. It’s a veritable “Who’s Who” of once-proudly validated companies. Big names, hot startups, none are immune. Between the sunset timeline and the active removal of modules that are no longer compliant, the herd has been severely thinned.

The takeaway? Maintaining FIPS 140 validation is really hard! It’s not “just one big push” to get on the list anymore. It requires constant vigilance to stay on top of the updates and to keep up with NIST’s reinvigorated policies. A more active CMVP can seem like a pain in the ass at first glance, but it is ultimately better for the industry. Nobody (except for lazy vendors) benefited from old, insecure, ‘grandfathered’ modules remaining on the active validation list. A stringent, active CMVP has embraced their role as a clearing house and it increases the value of the modules that do satisfy current standards. And I think they’re doing a great job.

This underscores the strategic significance of relying upon SafeLogic to complete and maintain FIPS 140-2 validation. As I tell folks every day, this is our focus. Our business is based upon the proper production of FIPS-compliant modules and their subsequent validation. Our customers reap the benefits of our work, and we succeed by scaling it, replicating our effort and leveraging our niche expertise for each client. CryptoComply is smooth and RapidCert accelerates the initial validation, but our customers have really appreciated the value of offloaded maintenance for the certificate. We talk a lot about the time, money, and effort with the traditional process, and the savings realized when using SafeLogic are growing. The delta is getting wider.

I scratch my head when a product manager boasts that they plan to roll their own crypto and get it validated. There are no bonus points for suffering in-house or for reinventing the wheel. When you hire consultants to complete a validation, you’re paying a premium for a single push, when the maintenance really is a constant effort. Consider those costs in time, money, and effort to complete your initial validation – and then add a multiplier for every revalidation you anticipate. It will be at minimum a quinquennial (every five years) project, and that’s if you’re lucky enough to avoid any other pitfall. The math doesn’t lie – the traditional path to FIPS 140-2 validation has become cost prohibitive. And if you’re pursuing Level 2 or Level 3, you still need a solid crypto module at the heart of the product. Using CryptoComply ensures that component meets the necessary requirements, again saving time, money, and effort.

CryptoComply is proven, again and again, to continually meet standards and retain its validated status with NIST. This is one of those situations where you don’t need to be creative. Choose SafeLogic, let us take care of the crypto, and you can get back to doing what you do best.

Written by Ray Potter

11 Jan 2017

CMVP Action to Deter Misuse of ‘In Process’ Status

CMVP Acts to Deter Misuse of In Process StatusJust before the winter holiday, sneaking in with very little fanfare, CMVP issued a statement on the treatment of modules that are pending FIPS 140 validation. Our friends at Acumen Security had a good rundown at their blog of the nuts and bolts of the guidance. (Go ahead and read it if you like. I’ll wait.)

In a nutshell, the CMVP has promised action to put pressure on folks to actually complete their validations. Imagine that! They have capped IUT (Implementation Under Test) modules at 18 months, which is entirely reasonable for anyone that is making a good effort to move forward. If you’re past IUT and on the MIP (Modules In Process) list, response time expectation has been dropped from 120 days to 90 days… and you get booted from the list if you fail to respond. Again, it’s very reasonable. 3 months to respond to CMVP’s questions is far more than you need if you’re actively pursuing certification.

It’s laughable for SafeLogic customers, of course. RapidCerts are on the IUT list so briefly, if you blink, you might miss it! In fact, the 90-day response time for MIP is longer than our entire process! This really will only potentially affect projects that are dragging their heels.

NIST hasn’t said as much, but industry insiders are speculating that the 18 month window is just the first stake in the ground and will be reduced in the future to a tighter timeline. We saw the writing on the wall when CMVP separated the Modules in Process (MIP) list from the Implementation Under Testing (IUT) list and annotated them with the dates of addition.

So why establish the sunset date? The most obvious answer is that NIST is tired of vendors claiming conformance (pointing to their In Process status as evidence) when they aren’t making an honest attempt to actually complete validation. Some consultants have made a sport out of trying to game the system… it’s practically highlighted as a specialty on their list of services! Front-loaded contracts for FIPS validation incentivize consultants to make the bare minimum effort, filing the initial paperwork, and getting their client added to the IUT List. Then it’s the federal agencies that are an accessory to the charade, subjectively giving certain vendors a free pass, approving the procurement of some solutions while they are still in IUT – potentially violating encryption and compliance mandates. Any child in school could explain that taking a test is not the same as having passed it, and yet our nation’s best and brightest shrug and say “Well, we wanted it, so we got it anyway.”

I think NIST has had their fill of being the unintentional enabler of this behavior. With an 18-month sunset applied retroactively, and the potential to tighten that window further in the future, the semantic games are on the way out. IUT is intended for vendors making progress, not as the goal itself, and that is being made very clear. We’ll see how many modules are cleared out on the first sweep and how many suddenly make progress now.

We should applaud NIST and the CMVP. The public IUT list was supposed to be a status update, a checkpoint, not the goal itself. It was available as a reference for federal agencies, to be reassured that negotiating procurement terms in advance of an impending validation would be worthwhile. I don’t know when agencies began on the slippery slope of deployment before certification, but it’s a dangerous policy and must be stopped. The IUT status by itself is worthless, and acting otherwise will devalue the FIPS 140-2 validation program if it’s allowed to continue.

Now, more than ever, as we approach the transition of power to a new presidential administration, the federal government must play by the rules – especially the ones that they themselves have set. NIST is doing a commendable job adjusting on the fly to ensure the best possible future of the CMVP and to make sure that vendors who play by the rules aren’t hung out to dry.

BlogFooterWalt3

22 Dec 2016

FIPS Module 3.0 for OpenSSL 1.1 Update

(L to R) Tony Busciglio (Acumen), Ashit Vora (Acumen), Mark Minnoch (SafeLogic), Steve Marquess (OpenSSL) Not pictured: Ryan Thomas (Acumen)

(L to R) Tony Busciglio (Acumen), Ashit Vora (Acumen), Mark Minnoch (SafeLogic), Steve Marquess (OpenSSL) Not pictured: Ryan Thomas (Acumen)

In December, Acumen Security hosted our kick-off meeting for the FIPS Module 3.0 validation effort. I was SafeLogic’s delegate, Steve Marquess represented OpenSSL, and Ashit Vora, Tony Busciglio, and Ryan Thomas attended for Acumen. With the expected adoption of TLS 1.3 and upcoming algorithm transition deadlines (outlined in NIST SP 800-131A), the OpenSSL-SafeLogic-Acumen Security partnership strives to deliver a FIPS module that works with OpenSSL 1.1 during the 2017 calendar year.

For this project to be successful, we will need additional Project Sponsors. Technology vendors that plan to deliver products using OpenSSL 1.1 in the future should consider sponsorship to support the effort. Financial contributions from Project Sponsors will help fund the engineers developing the code (OpenSSL) and the FIPS Laboratory (Acumen Security) for their validation testing services.

Here is the tentative schedule for the FIPS Module 3.0:

January 2017: Receive initial contributions from Project Sponsors
February 2017: Technical parameters locked in for development
March 2017: OpenSSL team begins development to meet FIPS requirements
May 2017: Development checkpoint
July 2017: SafeLogic reviews FIPS Module, finalizes FIPS 140-2 documentation
August 2017: Acumen submits FIPS 140-2 report to CMVP
October 2017: CMVP provides report comments to Acumen (2 month queue time expected)
November 2017: CMVP issues FIPS 140-2 certificate for FIPS Module 3.0 (for OpenSSL 1.1)

Important Notes:

1. Additional Project Sponsors are needed to make their initial contributions in January to begin the process on time.
2. All development and testing work is scheduled based upon sponsorship contributions being delivered as planned. Additional sponsors will mitigate risk of delays.
3. FIPS Module 3.0 Technical Objectives and Sponsorship information are available here: https://wiki.openssl.org/index.php/FIPS_module_3.0
4. Early releases of the FIPS code will be available from Github for public review and testing.
5. For a quick history of how the OpenSSL/SafeLogic/Acumen team came together, please see our July announcement.

How Can My Company Become a Sponsor?

Thank you for your interest! We welcome additional sponsors to support this crucial development for the community. Please contact me directly to discuss and stay tuned for additional updates here at the SafeLogic blog.

13 Sep 2016

Format Change for Modules In Process List at CMVP

Modules In Process ListThere has been a fairly significant change in the way that the NIST website displays the status of encryption modules that are undergoing FIPS 140-2 testing and validation. The NIST Modules in Process List website now contains two separate reports, drawing a clear distinction between Implementation Under Test (IUT) and Modules in Process (MIP).

The FIPS 140-2 Implementation Under Test List (IUT List) contains cryptographic modules that are in the testing process with a FIPS Laboratory. The IUT Date indicates when the cryptographic module was first added to the list.

Sample IUT List entries:

CMVP Modules In Process List

Once a report package has been submitted to the CMVP by the FIPS Laboratory, a cryptographic module will be removed from the IUT List and then added to the MIP List.

The FIPS 140-2 Modules In Process List (MIP List) contains the cryptographic modules that are stepping through the following milestones:

  • Review Pending – The CMVP received a complete report package
  • In Review – Report Reviewers assigned at the CMVP
  • Coordination – CMVP comments returned to the FIPS Laboratory
  • Finalization – Administrative processing to post the certificate

Sample MIP List entries:

CMVP Modules In Process List

Both lists are updated daily and available as PDFs from the NIST website. Note that participation is optional, and a vendor may elect to not be listed on one or either list.

What does this mean for my FIPS 140-2 strategy?

Essentially, the IUT status loses its luster. By drawing a clear differentiation between IUT and MIP, the former becomes simply a voluntary “We’re working on it!” claim while the latter signifies actual progress. Federal procurement officers used to check the In Process List and would be encouraged by any company appearing there, but the IUT list will become less important, especially for module entries that are months old and their progress has stagnated.

For SafeLogic customers, IUT status was never relevant in the first place. RapidCert catapults clients directly to MIP status because there is no delay between initiating the process and delivering documentation to CMVP. With our project management team and the processes already arranged with our preferred testing laboratories, SafeLogic customers will appear only on the MIP List during their brief waiting period for validation. Unless, of course, you prefer stealth mode. Imagine the looks on your rivals’ faces when you appear on the Validated List before they even make it off the IUT List!

As always, feel free to contact me with any questions. We’re ready when you are.

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.

BlogFooter_Mark

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.

19 Jul 2016

OpenSSL 1.1’s Big, Bright, FIPS Validated Future

SafeLogic is the Orange Knight!The OpenSSL project posted to their official blog today with some major news – OpenSSL 1.1 will be getting a FIPS 140-2 validated module! It’s a huge deal and the SafeLogic team is proud to be leading the effort.

In September, OpenSSL’s Steve Marquess explained in a blog post (FIPS 140-2: It’s Not Dead, It’s Resting) why the ubiquitous open source encryption provider would be hard-pressed to bring FIPS mode to the 1.1 release. With changes over the last few years at the CMVP, the viability of legacy OpenSSL FIPS module validations have been repeatedly threatened and the crypto community simply cannot accept the possibility of being without a certificate. An open source module with a communal certificate available is a crucial component that allows many start-up companies to test the waters in federal agencies and regulated industries before investing in a validation for themselves. Likewise, many major corporations have relied upon OpenSSL FIPS modules over the years as a building block for extensive engineering efforts. Without this commitment, many would have been caught in the dilemma whether to use the FIPS 140 validated open source module compatible with a rapidly aging, often-maligned older version of OpenSSL, or the new, sleek, secure OpenSSL 1.1, but without a FIPS validated module at its heart.

The choice will now be an obvious one, and the community can safely remove their heads from the sand and begin planning their future roadmap around a fully validated FIPS module for OpenSSL 1.1 and beyond.

As the OpenSSL team announced today, SafeLogic will sponsor the engineering work on the FIPS module and we will be handling the validation effort ourselves. (What, you expected us to hire an outside consultant? Surely you jest.) Acumen will be the testing laboratory, as they have been for many of our RapidCerts, and together we have high hopes for a smooth and relatively painless process.

Click to Tweet: Have you heard? @SafeLogic is leading #FIPS140 effort for new #OpenSSL #crypto module! https://www.SafeLogic.com/openssl-1-1-future/

One key element in the OpenSSL blog post that will surprise some folks:

“This is also an all-or-nothing proposition; no one – including SafeLogic – gets to use the new FIPS module until and if a new open source based validation is available for everyone.”

Why would we agree to that? For that matter, why would we take on this project at all, while other “leaders” in the community relished the idea of a world without validated open source options?

At SafeLogic, we are true believers in the importance of open source, in encryption and elsewhere. Past versions of OpenSSL have provided a basis for SafeLogic’s CryptoComply modules, so you may ask why we’re doing this – why we’re not just building it ourselves and letting the open source community fend for themselves.

Well, we thought about doing just that, but we decided against it for both altruistic and strategic reasons. We believe that SafeLogic has the chance to help not only the OpenSSL team, but the tech community at large. We realize that product vendors, government entities, education institutions, and other organizations need validated open source modules, and not all of them can or will implement SafeLogic solutions.

As a team, we believe that a rising tide lifts all boats, and we are putting that philosophy into action. The availability of an OpenSSL 1.1 FIPS module will provide greater security in regulated verticals and more opportunities for everyone working in this community. SafeLogic will be at the epicenter of the effort, of course, and I would be remiss if I didn’t mention that our success in this endeavor will push SafeLogic even further forward as the true leader in providing validated crypto!

Our central role in the effort will ensure that nobody has more expertise or knowledge in the design, operation and validation of OpenSSL 1.1 modules than SafeLogic, and future versions of CryptoComply will be the best yet. Trust me, our customers will reap the benefits. We are happy to put in the sweat equity on the open source communal validation, knowing that when product teams need a FIPS 140-2 certificate in their own name, custom work, integration assistance, comprehensive support or anything else related to OpenSSL 1.1 and FIPS 140-2, SafeLogic will be the obvious choice.

We’re very excited to work with Steve, the OpenSSL team, and Acumen, as we join forces to lead the OpenSSL 1.1 FIPS module through FIPS 140-2 validation. Stay tuned for updates!

For more information about the project, how to contribute, the future roadmap, or media inquiries, please contact us at OpenSSL@SafeLogic.com.

BlogFooterRay2

17 Jun 2016

Format-Preserving Encryption (FPE) in ‘FIPS Approved’ Mode

Vertical_Lock_ShortThe FIPS 140-2 Implementation Guidance (A.10) now includes vendor affirmation requirements for the format-preserving encryption schemes (FF1, FF3) specified in SP 800-38G.

As its name suggests, format-preserving encryption transforms plaintext to ciphertext of the same format and length. For example, format-preserving encryption may be used for a legacy application that needs to protect 16-digit credit card numbers and 9-digit social security numbers in a database without having to change their storage allocations. FPE has saved a lot of headaches in these use cases, as you can imagine.

For ‘FIPS Approved’ operation, until Cryptographic Algorithm Validation Program (CAVP) testing becomes available specifically for FPE, vendors will need to complete CAVP testing for the underlying AES algorithm, make documentation updates, and affirm compliance to SP 800-38G. Alternatively, SafeLogic can help you strategize and complete this process as easily as possible.

If you have a customer requirement to provide format-preserving encryption with FIPS 140-2 validation, then please contact us today.

BlogFooter_Mark