End-to-End Encryption, Why You Should Start Now

Bruno Morel, CTO, OroHealth
Bruno Morel, CTO, <a href='https://canada.cioreview.com/vendor/2022/orohealth' rel='nofollow' target='_blank' style='color:blue !important'>OroHealth</a>

Bruno Morel, CTO, OroHealth

In Canada, where our head office is located, a major security breach affected nearly 9.7 million Canadians. The organization's industry, banking, is one of the most security sensitive, with strict compliance requirements and practices. Despite all the measures in place, traceability and accountability built into their system, nearly 10 million people still had their information breached.

How?

From the inside.

One employee, with a little too much access, siphoned off most of the basic customer information, cross-referenced it in another separate system, and started selling it. Not only did they have access to more information than was strictly required to do their job, but they were also able, through indirect means, to gather more data.

As more organizations embrace the digital world and discover the complexity of giving their personnel the flexibility to work with modern tools, they struggle to keep it all separate, accessible and secure.

Whether it's holding hospitals in the U.S. to ransom or putting entire companies out of business due to a data breach, CIOs need to think about all possible forms of internal and external threats. While our cybersecurity awareness and security team are growing every day, the tools we use haven't changed much.

One specific tool in particular with which more and more users are becoming familiar, but isn't really getting inside and reshaping organizations' software but should: end-to-end encryption (E2EE).

 One specific tool with which more and more users are becoming familiar but aren't getting inside and reshaping organizations' software should: be end-to-end encryption (E2EE) 

As cloud technologies advance, the infrastructure and network layers themselves benefit from the underlying and top-notch encryption of the cloud provider, but most organizations end their efforts where it matters the most, where the data acquires meaning: the application layer.

 One major risk often overlooked is the disgruntled developer, or worse, the disgruntled devops: What would happen if one of these key players turned hostile?

How can we protect ourselves from a rogue system administrator?

And especially, when we talk about PHI, how can we protect our users/patients?

At ORO, we decided that we could not afford to wait for E2EE to become ubiquitous and easy.

We decided that our compliance with HiPAA, GDPR, PIPEDA, and all other legal frameworks to protect personal health information would not simply be a layer of human processes on top of a traditional user-restricted database, but would be encrypted end-to-end from the beginning and from the core.

We discovered early on that just putting encryption on top of our application was not enough. We learned that how we split the data into ‘usable’ chunks that define the ‘leak’ perimeter coupled with the management of who has access to the decryption keys was fundamental. By implementing coarse-grained encryption at the application level, we ensure to never leak users’ protected information during an infrastructure or backup breach. In the same way that those legal frameworks impose to identify and grade the type of user information, E2EE at the application level enforces those and gives guarantees that those barriers can’t be ‘moved’ by a privileged user or a smart hostile internal actor.

An interesting side effect is that it also makes it more difficult for mistakes to happen and PHI information to be accidentally or maliciously leaked, since the system itself does not have access to the keys, only the users -patients/doctors- do. No Developer, no DevOps, none of our IT, marketing, product or support team can access PHI in any environments without requesting it to an authorized, license practitioner.

That is also where we are lucky: we have a trusted actor that can and has the legal obligation to protect PHI. By using E2EE all through our platform we offer those guarantees to them and they fulfil any other legal requirement that would not be possible to meet as ‘operator of the E2EE platform’ without the encryption keys.

Not all companies can delegate the responsibility of the encryption key to one or multiple system users. In this situation, E2EE encryption can still happen, but it is necessary to weaken some of the guarantee by allowing a special privileged user (your CISO, your DPO?) some of those rights/keys and they, then, fulfil your legal requirement (ceasure, audit,...). 

In our case, once those fundamentals were ingrained into our platform, we went further ahead and addressed the more extreme case of having one of our PHI-privileges actors compromised, which implies a more complex "sea of hashes" encrypted data layer and should be a second step for most organizations.

As those threats grow and they will continue to grow, as our function as CIO becomes the management, grading and layering of security tools to protect data in increasingly complex ways, we need the best tool for the job at the top of our pyramid: E2EE.

Not just as a gimmick or to check a feature box, but by rethinking our product around E2EE implementation, limitation and impact on our users experience.

If you want to follow our path, we learned to first understand the impact to our customer’s experience by asking those questions:


  • What is our most sensitive or valuable data?

  • Of it, how can we separate each set into a valuable encrypted set?

  • Who should be able to decrypt and how small can we make the group access to a particular encrypted set?

  • How do we build tools, monitoring, performance and telemetry around the use of those encrypted sets and not their content?

Let's also be clear: it's not easy. Obviously, security and even scalability, since all the encryption is done on the client side, are fulfilled to a higher standard with E2EE. But all our other requirements such as compatibility, reliability, maintainability, usability and performance have to be adjusted or learned all over again to be solved at scale with E2EE.

I do believe that by witnessing all the incidents and their impact on their identity, financial health and privacy, and by experiencing the consequences of not using E2EE at home or at work, users will soon demand application-level encryption.

My advice: don't wait for them to leave you for an E2EE competitor. Start now.