What is a Cryptographic "Backdoor"?: Peerio
January 20, 2016

What is a Cryptographic "Backdoor"?

It’s been an exciting few months for Peerio as we approach our second anniversary this summer. We’re preparing to launch mobile clients for Android and iOS, professional plans for our heavy users, and we have a slew of features in the pipeline to improve overall user experience. As our team continues to grow, we’ve been accelerating development of a collaborative end-to-end encryption tool to ensure that everyone has access to a simple and secure platform to share private messages and files in the cloud. This has been our mission since Day 1 and it is a source of pride for the entire Peerio team who believe strongly in that mission.
While most of Peerio’s users and most observers understand this mission, there is some skepticism due to the tumultuous leave of one of our past teammates. In a Forbes article titled, Peerio Co-Founder On Why He Left The Company (Hint: It Had To Do With Admin Backdoors), the author discusses some of Nadim Kobeissi’s claims about Peerio and our goals, the core one being:

Peerio’s “CEO repeatedly pressured…to come up with ways to sell backdoored crypto to private clients.”

Since we pride ourselves on quality and transparency, we’d like to use this space to address claims like this one, give a bit more context to Nadim’s leave, and discuss some of the actual problems we think still need solving regarding end-to-end encryption for teams.

What is “backdoored crypto”?

A “backdoor” in crypto is generally understood as secretly including a weakness, vulnerability, or bypass in software so that someone unbeknownst to the user is able to access their private data.

This practice is both an act of bad faith and an example of bad technology, as users are led to believe their communications are secure, and there’s no guarantee that this vulnerability won’t be discovered by others.

Is there a “backdoor” in Peerio?

Absolutely not.

Nadim’s claim that Peerio planned to sell backdoored cryptography to enterprise – that is to say an intentional bypass in the cryptographic design to decrypt users’ communication without their knowledge – is purposefully deceitful. Any talk of a backdoor was quickly dismissed as being contrary to the Peerio’s values and technology. Independent auditor Cure53 demonstrated that rather clearly in their most recent audit, which was made public last week.

What we are seriously considering, as we will elaborate in the next section, is an optional multi-party authentication system that could actually enhance security and usability for many users, whether individuals, organizations, or yes — big enterprises. The highly-trusted Cure53, responsible for auditing platforms like SecureDrop, wrote that Peerio gave “an overall strong and secure impression…Peerio presents itself as prepared to handle and deter a large and diverse array of possible attacks.”

We’re proud to have worked with an expert team as thorough as Cure53 to assure our upcoming mobile clients’ security. Any claim from Kobeissi that a backdoor would be written into Peerio code is baseless. All versions of Peerio that have been released are secure, as verified by Cure53. To top it off, we’ll pay you to find this supposed “backdoor” or any other security vulnerability in Peerio.

“Backdoor” vs. “Organizational Trust”

In order to ensure the sustainability of Peerio, and subsidize development of the free application we build for everyone, other customized versions of the platform are designed for enterprise clients with specific needs. This quickly becomes a question of “use-cases”, or how different people and organizations actually use software in their work and what types of risks they face.

For everyone, no matter the type of user, the value of end-to-end encryption is its ability to protect data between any two given ends in a way that no unauthorized third party can gain access to the data. When it comes to one-to-one communications, this is simple, Alice and Bobby want to talk in a way that no one can listen in and figure out what they’re saying.

Things get more nuanced when you start working with teams. One journalist organization we spoke with had an exceptionally high risk scenario — what do you do if one of your colleagues is kidnapped or goes missing while covering a story? They told us fears like this led them to share their Peerio passphrases with each other, that way they could review recent communications and work if they needed to trace each others’ whereabouts if the situation became dire.

This is still end-to-end encryption, the journalists in this case simply gave more people access to the “ends”. Choosing to share your Peerio passphrase is not a “backdoor”, as clearly no unauthorized third party has access. Instead, this is an example of trust — trusting someone with your privacy so that they may be able to help you when you need it.

What is security for an organization?

While we certainly don’t recommend this, individuals and companies alike are free to share their Peerio passphrases with whoever they wish for whatever reason they see fit. We can’t stop a company from independently creating Peerio accounts for their employees and storing all the passphrases in a database so an admin can assist employees with account recovery. This isn’t unique to Peerio either, this is simply a key management workaround that some companies may utilize with encryption tools to solve common problems such as:

  • An employee forgetting their passphrase and needing to regain access to their account
  • An on-the-job incident, death or other urgent circumstances that resulted in a team member being unable to unlock their account, but their work being needed by the organization.
  • Being subjected to compliance regulations by professional orders that would legally compel the disclosure of someone’s communications

While this reduces the personal level of privacy of end-to-end encryption (e.g. Bob can access Alice’s account) and creates a centralized point of failure (i.e. that database of passphrases), it at least helps ensure that the data is encrypted and recoverable within the organization — no unauthorized third party has access (including Peerio).

These types of use cases and key management are real problems for organizations. We’ve seen this workaround implemented in quite a few organizations now, and as far as we can tell no one in the end-to-end encryption space is trying to solve it. We want to.

End-to-end encryption for teams (and everybody)

The role and value of end-to-end encryption needs to be understood differently to a team or organization than it is to individuals. When a company uses end-to-end encryption, their “ends” are not always individuals; “ends” may be teams, departments, specific roles or positions, etc.

Similarly, the risks that an organization faces are often quite different than those of an individual. In fact, individuals are sometimes one of the greatest risks to an organization. It only requires one person who acts either carelessly or maliciously to cause significant damage by leaking data, abandoning work, or operating in a ways that may get the company punished for violating legal or industry compliance standards.

When evaluating end-to-end encryption for an organization, we need to ask who and what they are trying to protect, and from whom? How can a company use encryption to secure itself from unauthorized third parties, while also managing and protecting itself internally from leaks and loss?

Multi-party authentication, encryption supported by trust

The idea of multi-party authentication is fairly simple; instead of trusting one person or database with the key to your account in case you need help recovering, what if you could split that key into multiple pieces that would only work when used together? You give pieces of the key to a few people you (or your organization) trust, and those people can recover your account key only by working together.

This model would give organizations a way to manage and recover team accounts without depending on any external third party, but doesn’t put all trust and accountability into a single person or database. This significantly reduces the risks of carelessness or maliciousness of any individual by utilizing a system of checks and balances to ensure that critical security actions are only carried out under specific circumstances. Of course, everything is still encrypted within that organization — only the team setting up this feature would have this type of control.

At any rate, this feature is still in a research and development phase, and any talk of it is still theoretical. It would be subjected to independent audits, as is the norm for us when developing any significant new feature. It would also be entirely optional for free users or companies who want an account recovery option. Anyone who doesn’t want or need this functionality can simply not enable it.

Our Split with Nadim

We believe that reality presents many complex security questions for any individual or organization. There are intricate sets of human relationships, workflows, software requirements, and use-cases that need to be addressed. We strongly believe that there is no simple universal one-size fits all solution. This put us at odds with Nadim, who had a more purist view of end-to-end encryption. When we say “purist”, we mean a definition wherein Alice, and only Alice, is able to access her account. We too support this as the pinnacle of end-to-end security.

That said, it becomes obvious pretty quickly how this model fails to scale when working in an organization where people forget their passwords regularly, where there is personnel turnover, and where very real legal considerations need to be taken into account that may require providing data from certain employees. It becomes obvious that real people’s security problems can’t be solved with a model this simple.

Nadim refused to work on these types of problems, as he felt this was a disservice to his view of end-to-end encryption. We wanted to progress to innovative solutions that provided higher levels of organizational security than have been seen with unencrypted systems. This disagreement became tenuous as Nadim served as Peerio’s Chief Security Officer, and culminated in his abrupt choice to leave Peerio.

Unfortunately, his opposition and anger was not simply theoretical, but involved multiple aggressive, abusive, and inappropriate actions during his time at Peerio and towards individual team members after his leave. This portion of the story is a personal matter that our staff who was involved in the matter would rather not relive or delve into, but we feel is essential to give context to the rage Nadim expressed on Twitter.

Dispelling other claims

Beyond the main critique of Peerio’s encryption and security, Nadim made some other interesting claims. To set the record straight, we’ve provided information about Peerio and our side of these claims.

“Peerio’s open-source E2E crypto client’s a front, owned by oil equity firms, main plan is to sell backdoored crypto to enterprise.”

This is just patently false. No equity, debt, or any other Peerio asset is owned by oil industry firms. The following are details that Nadim is well aware of.

Our CEO, Vincent Drouin, has a history of sales in security software spaces as well as independently developing and maintaining a service for art auctions.

Our CTO, Florencia Herra-Vega, previously worked as a developer consultant for years, organizes popular education programs on topics ranging from sexual health to introductions to coding, and has been on the boards of Montreal non-profits for over a decade.

Our CPO, Skylar Nagao, comes from an academic humanities background and founded a non-profit focused on making burritos and delivering them to people living in the streets of Montreal.

Our principal investor works in the theme park entertainment industry.

Peerio “attempted blackmail to gain exclusive rights over miniLock, by withholding shares.”

As per the contract signed by Nadim, miniLock (the file encryption protocol that Peerio is based on) remains his property but “can be used by the Company where relevant.” This is a simple oversight of his release agreement, which explicitly states:

“Mr. Kobeissi hereby grants to Peerio…a non-exclusive, perpetual, irrevocable, worldwide, assignable, royalty-free, full paid-up license to use and fully commercially exploit the software in connection with its business.”

In other words, after helping build Peerio around miniLock, he’s not allowed to say we can’t keep working on Peerio using that technology.

Of course, there was no “blackmail” and no such evidence exists. Weeks of delays were caused by Kobeissi as he sought a legal opinion and ultimately declined to sign the agreement. Despite his lack of cooperation, Kobeissi’s shares were mailed within days of his decision. We received confirmation Kobeissi had received the shares on August 27, 2015, and the matter is now settled.

Peerio “attempted to prevent me from disclosing and by threatening to sue, asked me to sign contract that I’d never tweet about Peerio.”

Non-disclosure agreements are exceedingly common and no “threat” was ever made. In fact, he repeatedly threatened us that he would use his social influence to make claims against us when he was agitated. In Peerio’s view the issue with Nadim Kobeissi has concluded, though the company reserves the right to defend itself in court against unquestionably false and defamatory statements about the technology or employees.

It’s unfortunate that the Peerio team had to be momentarily distracted by what amounted to an irrational and aggressive attack from a former team member who was consistently at odds with colleagues and exhibited a destructive attitude toward the company. The team remains unwavering in its commitment to working toward the goal of providing simple and secure communications for everybody.

We value transparency, if you have any questions or concerns, feel free to write the Peerio team at peerio@peerio.com.