Let’s articulate what benefits zero-knowledge service brings and what it takes to provide a zero-knowledge type of service

Key Points

· An online zero-knowledge system is designed in such a way the data it maintains will only remain accessible to the true owner of the data, not to any other party (not to even the developer, operator, admin or builder of the system)

· This high level of confidentiality and protection is a paradigm, not an attribute to be added to an existing system easily and can only be baked into the system from day “-100” and changes the DNA of the system and every design decision and is hard and complex to achieve

· Zero-knowledge systems are harder and more expensive to build but they provide exceptional protection against data breaches and remove the need to trust the builder/operator of the system

· Zero-knowledge design is the utmost level and the real materialization of “privacy by design” and “zero trust”

· In essence, when adopting a zero-knowledge system, one gets a mix of the 2 worlds of not having to deal with the trouble of running and hosting the system privately (as in most cases the service is cloud based) but yet, enjoying the utmost privacy, confidentiality, secrecy and data protection that would have been achieved only if the system was privately and locally run and hosted

· As long true zero-knowledge has been truly achieved in the design of a system or service, its adoption poses much smaller ‘trust related’ risks, since it directly affects both likelihoods and consequences of data breach incidents, hence reducing the risk (which normally is a multiplication of the two)

· There are use cases like Confirmation of Payee for which a zero-knowledge service helps avoid trusting a centralized repository which may be the only way to solve problems

Cloud Computing Models

Different cloud computing models exist for different purposes and come with different merits and demerits. Infrastructure as a Service, Platform as a Service, Software as a Service are the mainstream ones. From the first to the last, control and maintenance accountability are reduced and the level of granularity of elements/components increase. With Software as a Service, an adopter would basically and in principle buy a complete software as a service where as with Infrastructure as a Service, an adopter would but infrastructure to run their own services on.

Trust, the Price of Convenience

Cloud computing made a lot of things easier. One important improvement they brought was the way they help with ‘the right to access data anywhere, anytime’. This, however, came with a catch. You would have to trust a cloud-based product or platform to maintain your data on your behalf to provide access to it to you anywhere and anytime. In essence, when adopting a cloud service, you have to trust the provider that in some form or shape, the data that you own becomes available in plain format on the infrastructure owned by the cloud provider.

This ‘trust’ requirement, at first, was framed as a legitimate cost of ‘cloud’ business and it made sense at the beginning. A decade on, more and more, it has become more reasonable to try to think of the high levels of trust in this model. There are use cases for which organizations have had to retrieve back from cloud hosting to on-premises hosting of their systems merely because of this huge level of trust requirement. For these reasons, up until very recently, two versions of some cloud based products like TFS or Jira had to be maintained, one cloud-based and one on-premises. Even the idea of sunsetting on-premises versions of such products has not been able to force certain organizations to ‘accept’ that they have to trust cloud providers to maintain and handle their data without any protection.

The underlying issue is ‘choice’. Forcing everyone under the banner that ‘we have to be trusted’ or that ‘oh, everyone else is doing it this way’ are no answer for this problem in certain scenarios.

What It Takes to Build Zero-Knowledge Services

Zero-knowledge design for a service implies that the provider of the service must not maintain a knowledge of the data service handles at all times. In most occasions, it can only be achieved if such data remain available in plain format only at client side. This way all what is maintained server-side is encrypted with keys that are unavailable and unknown to the service provider at all times.

This brings along a range of design challenges and consequences. For example, for a zero-knowledge database, many server-side querying abilities remain unavailable because the data-to-query is not available in plain format to the server and has to be decrypted into plain format at client side. Obviously, for such a server to be able to execute queries on the data, it would have to have utilize a range of concepts like homomorphic encryption to be able to perform some basic tasks against the encrypted data or specific types of indexes that help with ordering data without knowing what the data actually is but in general, there is a dependence on privacy-preserving or private client-side edge computing resources in zero-knowledge systems and that’s logical.

Zero-Knowledge At-Rest Storage vs Live Processing

In a true zero-knowledge service, the edge of the network (i.e. client side) is the only place data is available in plain format. Such systems should also be designed with this in mind that even the traffic and data sent to servers should not leak ‘knowledge of the data’ to the server. This means even processing of such data remains a challenge on server side in a true zero-knowledge system.

A true zero-knowledge service must maintain no knowledge of the data it handles even at the time of processing, not just at the time of storage. This is different from zero-knowledge “storage of data” that at some point, gets decrypted and processed server-side in plain format.

An example of “zero-knowledge storage” of data applies to cases where by using client-owned secret management, such data is encrypted using Data Encryption Keys (DEKs) which get encrypted using asymmetric Key Encryption Keys (KEKs) the private component of which remains unknown to the cloud provider. This facilitates a storage model in which the cloud provider does not maintain a knowledge of the private keys by which actual data encryption keys are protected, however, such data may get processed in plain format by server-side components which means the cloud provider can, in principle, develop knowledge over such data if they intend to and one still needs to trust they don’t.

A significant part of true zero-knowledge s to remove the necessity of trust in all its forms and shapes, and as you can observe, that is a big design challenge.

Benefits of True Zero-Knowledge Service

Zero-Trust and Elimination of the Necessity to Trust the Provider with Your Data

This benefit is a significant tipping point when making product adoption and systems acquisition decisions. When you are confident that your client’s data remains only available to you, and not to the service provider, a range of necessities become redundant, including the necessity to seek the consent of your customers that their data is going to be shared with other vendors.

It’s worth mentioning when using a typical service or system, the assumption is you would share your data with the service provider and that they have implemented checks and balances to protect the data. In a view, the service provider implies that every party expect the adopting client and the service provider are deemed ‘unauthorized’ to access the adopting client’s data.

In a zero-knowledge service, however, the service provider is also put in the category of unauthorized parties using cryptographic barriers so that even if the provider intended to, they could not have access to the client data. Hence, a zero-knowledge service does simulate the extreme protection of a self-hosted service without the hassles and troubles of running one!

In other words, zero-knowledge services are resistant against insider attacks where as non-zero-knowledge services are subject to insider attacks.

Elimination of Centralized Trusted Parties

Depending on use cases, there are scenarios where a zero-knowledge service can be the only available option when trust-full alternatives may lead to the formation of a centralized trusted intermediary.

The Difficulty of Cross-Organizational PII Verification and ‘Confirmation of Payee’ includes a deeper view on why for certain cases, forming such trusted intermediaries can require a while bunch of other pre-requisites like regulative softening, changing privacy and data sharing regulations, building data sharing treaties between firms and countries, and finally, creating consensus and a consortium of many firms to accept and opt into the new data sharing arrangements.

These pre-requisites and their complex implementation was the original driver for Payee-Auth.com.au to take a zero-knowledge zero-trust approach to build the world’s first universal zero-knowledge privacy-preserving cross-firm and cross-country PII verification platform.

Minimizing Data Breach Consequences

Yet again, when you are confident that your data is not shared with the service provider, even if the service provider was to get breached, maximum level of cryptographic protection would already be in place to render the data held by the service provider already unusable and unreadable by any adversaries. This would imply in order to have access to the data, an adversary would either require the private keys (owned and maintained by the client) or try to break such keys which would impose a significantly large computing cost (e.g. millions of years’ worth of computational costs).

Minimising Adoption Risks and Costs

ISO 3001, the International Standard for Risk Management, cites that any risk can be a multiply of two components: the likelihood and the consequence of an adverse event preventing outcomes.

Given that a zero-knowledge service combines the benefits of cloud with the protection, confidentiality and privacy of a privately-hosted service, a number of likelihoods and consequence levels of a number of risks can be reduced by adopting it, including the followings:

· Consequences of a likely breach of data that may occur to the service provider

· Likelihood of adverse scalability issues compared to a self-hosted private service

· Likelihood of adverse availability issues compared to a self-hosted private service

· Likelihood of data loss compared to a self-hosted private service

Given the combined benefits of cost-effective trouble-less cloud service and the privacy and confidentiality of a self-hosted private but expensive-to-own-and-run service, cost effectiveness can also be considered an important improvement over a non-zero-knowledge cloud service.

Conclusion

Without a doubt, resistance against insider attacks and promoting an easier pathway to scale for certain multi-firm data sharing scenarios can be named as the biggest benefits of a zero-knowledge service. All these benefits, however, come at a higher cost for the developer of such systems who require certain expertise and a longer runway to deliver on their product targets.

The Payee-Auth.com team is proud to have achieved this goal, aligned with our sister venture Xiippy.ai which provides world’s first privacy-preserving data-rich payments, in-store and online, powered a zero-knowledge SaaS dashboard.