Blog | SafeLogic

Blog | SafeLogic

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.


29 Dec 2016

Happy New Year from SafeLogic

Well, it’s that time of year. You know, the annual, happy-go-lucky, turn-the-page-on-the-calendar, celebrate-the-new-year, use-too-many-hyphens blog post.

I’ve been reflecting on the beginnings of SafeLogic – how we got here, where we’ve been, and where we are headed next. Most of those reflections have been pleasant, but certainly not all. There’s no need to put lipstick on it. The nearly two years that I went without salary weren’t exactly “fun” and I’m glad that’s in the past. Or the times I felt like an inadequate leader because it felt like we weren’t living up to the ridiculously overblown expectations of Silicon Valley society. Or the times we invested in new ideas only to find failure (which is not a bad word, by the way).

high-fiveI’m still thankful for all of those things because it put SafeLogic on a path that almost leaves me (yes, even me!) speechless. Those sacrifices were made with the future in mind, and we are now reaping the benefits. We’ve had so many positives this year that bullet points hardly seem to give justice to the significant effort behind them, but here are some quick highlights:

– We added a dozen new customers and strengthened relationships with existing customers.

– Revenue doubled from last year. (That’s good, right?)

– The number of support tickets decreased over 50%, signaling that the growth of our self-serve knowledge base is paying off.

– Average Time to Resolution on those support tickets is a fraction of what it was last year, a testament to the increased effectiveness of our technical team.

– 100% of support contracts were renewed. Always a good sign of customer satisfaction!

– Strategic additions to the team fueled these successes, which of course will then make it possible for more expansion. A very positive cycle.

On a personal note, I left the corporate world nearly 12 years ago to work for myself and at this very instant, I’m the happiest I’ve ever been. This is a journey that I could not undertake alone, and this team is the real deal. We have great products that customers want and need, and we help them solve real problems in innovative ways. Internally, we’ve grown and matured to the point that we are able to handle roadmap items and customer requests much more aggressively and proactively (and in some ways, automatically, which is extra cool).

So does all this reflection mean that we’re hitting pause because the CEO is happy? Oh hell no. We are just hitting our stride! Being content is nice, but never complacent. 2017 will be the year of more business innovation, of more new capabilities, of more milestones. Of, well, more.

This leads me to the mushy part:

Thank you, SafeLogic customers. Thank you for believing in us and we promise not to let you down as we continue to grow. Thank you, SafeLogic team. Your hard work and commitment is appreciated more than I can express. Thank you, SafeLogic partners, friends, and allies for your support, advice, and contributions.

Here’s to a stellar 2016 and to keeping the momentum going in 2017!




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:
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 Dec 2016

RapidCert for CryptoComply | Java 3.0 Is Available!

CryptoComply | Java 3.0 is here!You may have noticed – SafeLogic has a new FIPS 140-2 certificate posted by NIST. Published on December 8th, it’s our CryptoComply | Java module, version 3.0! Fully compatible with Bouncy Castle’s recent FIPS API revisions and with a nice helping of SafeLogic’s secret sauce (yes, it’s orange), customers with Java deployments now have a natural upgrade path available with CryptoComply | Java 3.0.

Technical improvements over CryptoComply | Java 2.2 include a variety of bugfixes, a significant simplification of deployment, a single JAR that includes both approved FIPS mode and non-approved mode, and the promise of greater forward compatibility. Many of you are already aware of the technical benefits of Bouncy Castle’s latest release, and now SafeLogic’s CryptoComply offering includes RapidCert, which delivers your own FIPS certificate quickly. With a validation in your name and support from our technical staff, CryptoComply is a clear upgrade. See our Top 10 Reasons to Choose SafeLogic Over Open Source Encryption for more!

RapidCert is available NOW for CryptoComply | Java 3.0
License the software today and have a certificate in your name in 8 weeks.
It really is that easy.

Contact us immediately for a quote.



23 Nov 2016

Inauguration to Bring Spike in Federal IT Spending

inauguration to bring spike in federal IT spendingLast week, I was part of SafeLogic’s delegation to the Immix Federal IT Sales Summit. This event is in its third year and has already become a must-attend for any company that wants to get a piece of the government money pie in the year ahead. (If you’d like to attend next year, drop me a note. We will have some complimentary passes available.)

I’d like to share details about one session in particular, a panel led by Allan Rubin, titled Taming the Transition: Marketing & Sales Tactics for a Year of Turnover. Five experts weighed in on the impending ‘Trumpification’ of the U.S. government and there were some key strategic insights that you may find interesting.

First of all, the focus is on January 20, 2017. That’s the inauguration, of course. We are firmly in ‘lame duck’ territory at the moment, but the new administration of Mr. Trump, Mr. Pence, and their slate of appointees is lurking on the sidelines. We have a little more than 8 weeks from now to prepare for transition day and to determine how best to benefit from the change in power.

(Yes, 8 weeks from now. Do I need to point out that our target delivery for RapidCerts is 8 weeks, often less? Good fortune indeed!)

Panelist Frank McDonough pointed out that the hiring freeze can produce erratic purchasing behavior. The election year has already disrupted the traditional ‘use-up-the-end-of-year-remaining-budget’ spending spree. Our customers have reported varying behavior from agencies – some accelerated their buying cycles before the ballots were cast, while others tried to conserve resources to be used during the anticipated hiring freeze at inauguration. Unpredictable is the best way to describe what we saw this fall.

Mark Amtower, Kris van Riper, and Barbara Austin joined McDonough on the panel and echoed him on one major point in particular – incoming appointees will be under pressure to make their mark. They will be ready to spend money and will assert themselves with an immediate splash. McDonough said that in the past, appointees averaged approximately two years in office. I don’t think anyone, including the newly tapped leaders themselves, will expect President Trump to have ‘average’ patience for his team. We are all accustomed to his catchphrase “You’re fired!” and why would that change? They will all be on the hot seat from Day One at the inauguration.

Federal appointees will be now, more than ever before, aware that they are serving at the pleasure of the President, and appearances will be extremely important. When they make major purchasing decisions, they will be highly concerned with how it will look to the White House. Will they be willing to ignore mandates, such as FIPS 140-2? What if it comes back to bite them? As it appears many appointees will be coming from the private sector, will they even have the bureaucratic expertise to successfully dodge regulations, as they have in the past? Oversight from FITARA (the Federal IT Acquisition Reform Act) looms larger than ever before, and federal procurement officers may be held to tighter standards than in the past. Sole source contracts may be seen as too risky, potentially removing a once-popular method for agencies to defy NIST and acquire unvalidated products. Nobody will want to put their job on the line to procure a piece of software, no matter how great it is. The ever-present threat of Trump’s chopping block will drive a renewed devotion to compliance… and that’s not a bad thing, unless you have been trying to skate by without certification.

By achieving FIPS 140-2 validation with SafeLogic, you are creating a very tangible competitive advantage. The new culture in D.C. will provide huge opportunities to those who embrace it, because agencies will have big incentives to spend significantly front-loaded budgets on splashy new technology that meets regulatory compliance mandates.

If you already have a current and valid certificate, go ahead and pat yourself on the back. If you’re not certified, what are you waiting for? Contact us immediately so we can help you assess compatibility for CryptoComply and set a target completion date for FIPS 140-2 validation in your company’s name.

Don’t wait too long… January 20th is approaching fast! If we move quickly, your certificate will be completed by Inauguration Day, perfect timing for the impending spike in federal IT spending.


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.

7 Sep 2016

How to Read a FIPS 140-2 Validation Listing

I’m pleased to provide a breakdown of exactly what you will find on the NIST website when reviewing a FIPS 140-2 validation listing. Whether you are a federal procurement officer, a technical consultant, a vendor representative, an end user, or really any role that may deal with FIPS 140-2, you should be able to interpret and verify the information on these certificates after reading this post. Bookmark this page for future reference, in fact. If you have any further questions, please don’t hesitate to contact me directly at I’m here to help.

Here is a screen-captured example of a FIPS 140-2 validation listing, as shown on the NIST website. I will note where other validated modules may differ, but this is a good sample of a typical Software Level 1 certificate, the specialty of SafeLogic’s RapidCert program. (If you click here or anywhere on the image below, it will open full-size in a new tab.)

How to Read a FIPS 140-2 Validation Listing

  1. The unique FIPS 140-2 validation listing number assigned to this cryptographic module. This is the number that a vendor should reference when relevant. In this example, FinalCode would announce, “Our products use FIPS 140-2 validated cryptography, see certificate #2717.”
  2. This is the validation owner. Company names include an embedded link to their website, and the physical address is provided by the vendor. It may not always be headquarters – sometimes it is a development office or similar.
  3. Every validation listing includes contact information. Often it is the product manager, CTO or another development stakeholder. In this example, it is a general mailbox and central phone number, which is also acceptable. Note the embedded link for direct email.
  4. This is the independent third party testing laboratory. Every validation has one, and it’s not possible to earn your FIPS 140-2 without an accredited lab. This particular example was tested by Acumen Security, which has done a fantastic job on many SafeLogic’s RapidCert efforts. Information on all the accredited labs can be found here: and you can cross-reference the unique NVLAP (National Voluntary Laboratory Accreditation Program) code if you like.
  5. Every FIPS 140-2 validation listing has a name. They are usually pretty generic, just for simplicity, but federal agencies must verify that the specific version information matches the module version implemented by the product(s) that they are using.
  6. The caveat section contains information required by the CMVP for the cryptographic module. Common caveats describe “FIPS mode” and entropy, a hot button issue of late. CMVP also recently added a new reference, if another validated module has provided a basis for this certificate.
  7. A link to the consolidated validation certificate. CMVP realized that it was a real time suck to create individual certificates (and send them via snail mail), so instead, they publish a single certificate each calendar month, which lists the validations completed during that period. The PDF certificate includes signatures from both NIST and CSE and it looks pretty, but they are rarely referenced because the public website listing includes more information.
  8. Each validation includes a required Security Policy, which is linked via PDF. This documentation includes technical parameters for the cryptographic operations in FIPS mode and represents a significant portion of the time and effort wasted by vendors who insist on handling their validation in-house. With RapidCert, this documentation is already prepared for CryptoComply modules and is updated for client needs. Much more simple than starting from scratch.
  9. This FIPS 140-2 validation listing example features a Software validation, but CMVP also validates Hardware, Firmware and Hybrid modules.
  10. This is the completion date of the validation. If multiple dates are listed, those represent approved updates. Note that beginning in 2017, CMVP will be removing validations that are not dated within the preceding 5 years. This is an important step to ensure that all validated crypto modules are being maintained for compliance with current standards and requirements.
  11. FIPS 140-2 validations can be completed for Level 1, 2, 3, or 4. While Level 1 is appropriate for Software, the advanced levels feature increasing amounts of physical security, including tamper-evident seals and tamper response. These are key facets for Hardware validations, in particular.
  12. This is an area for Security Levels that differ from the Overall Level (see 11) or additional information. These may include notes in the following categories:

– Roles, Services, and Authentication
– Physical Security
– Cryptographic Module Specification
– EMI/EMC (electromagnetic interference/electromagnetic compatibility)
– Design Assurance
– Mitigation of Other Attacks

  1. The Operational Environment is a crucial section for Software validations. This is where it becomes explicit which platforms were tested within the scope of the validation. This example includes both Android and Apple iOS mobile operating systems. Note that it may be permissible to operate FIPS mode on other operating environments that are not listed here (by vendor affirmation that the module did not require modification for the unlisted environment).
  2. The FIPS Approved algorithms section lists the specific cryptographic algorithms Approved for use in the FIPS mode of operation, as well as references (but not embedded hyperlinks, unfortunately) to the CAVP certificates for each. This is the evidence that each algorithm was successfully tested by the lab as a prerequisite for the module testing.
  3. Other algorithms are included on the FIPS 140-2 validation listing if they are implemented in the module but are not specifically listed as FIPS Approved algorithms (#14). This list includes algorithms allowed for use in the FIPS mode of operation as well as any algorithms contained in the module that are not to be used in the FIPS mode of operation. The latter category may be algorithms that have been phased out or are included for other strategic reasons.
  4. This is a categorization of the module. Multi-Chip Stand Alone, Multi-Chip Embedded, or Single Chip. Software modules are classified as Multi-Chip Stand Alone since they run in a general purpose computer or mobile device.
  5. This is a brief summary of the role of the cryptographic module. Some are extremely brief, while zealous marketing folks have written others, but the vendor always provides it to offer some context.



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.