Zero Knowledge Trust Security Technology for Cloud Applications 11 Dec 2025

Zero-Knowledge Trust (ZKT) or as near as

One of the challenging features of being on the Internet is this top down approach of using providers to identify yourself as you move around the Internet. Our prediction is that as soon as digital ID takes hold this will become a riskier affair. The vast majority of Internet users have the same password across many sites. One way to overcome this is to use a password manager generating passwords per website. This can offer some inconvenience if you are using hundreds of apps and websites across devices. One way to overcome this is integrated password managers to overcome this but you still typically end up signing in with a well-known identifier such as an e-mail address.

If you are genuinely interested in finding out if Zero Knowledge Trust can work for you, reach out at solutions@inforhino.co.uk or commercial@cryptostatto.com

Our solution is middleware and multi-point storage of secured data to minimise downtime.

Framing the problem- "If you have nothing to hide, then there is nothing to fear"

As a data engineer and application engineer, the "if you have nothing to hide, then there is nothing to fear" statement is total ignorance. When we build data analytics systems, the data model must be perfect, the granularity and state management of the software must be perfect.

A simple example could be relying upon auto complete to fill a text box, not verifying and submitting. Suddenly, an incompatible data point is audited against your digital footprint. Imagine a web page's code linking a social media post you didn't agree with. Perhaps you inadvertently liked a post?

We are sold that AI is super-intelligent and can overcome data quality issues. It cannot solve everything. AI is still trained by historical data that can itself be flawed. Few understand that LLM is non-deterministic. Open two sessions of LLM and ask it to solve a maths problem, it will come up with different solutions and sometimes, different answers.

In a world of independent agents attaching data to activities around you, everyone has something to avoid being linked.

Indeed, a better response would be - "Everyone has data that would be preferably not linked."

We find ourselves at a nexus, do we give independent use-case systems the ability to be connected to bigger systems that will ultimately make incorrect inferences, or do we simply ring-fence systems within the confined of their limited reach?

More succinctly, larger platforms are performing this data linking already so why create more potential for entropy?

Ask yourself. There are undoubtedly scammers on social media but is uploading a document and verifying data ID safe for the individual?

Caveats on ZKT for Crypto Statto

Our goal is to ensure that we do as much as possible to avoid us accessing customers security details they use to connect to trading exchange API's. Ultimately we wish to protect ourselves from data breaches and leave the responsibility in the hands of the customer. It is very much the same principle as Bitcoin with safeguarding your private keys.

The security headache for platforms such as Crypto Statto

Within our main website and our wider used web data platform we implemented multiple e-mail address capabilities. By entering one or more e-mail addresses you can register sign in and sign out from our website. We also implemented bearer API based token authentication by giving the user keys to accompany their e-mail accounts.

The vast majority of visitors to the site don't have more than one e-mail address which is shocking to technologists such as ourselves. Worse, many within the crypto space are naturally distrustful of doxing themselves by using e-mail addresses.

The confusing point here is that users can easily set up aliases to forward emails to a single e-mail address. However many users are not that technology savvy and stare in bewilderment at the options provided.

It has been a long standing task, we had on our tasklist to improve the security.

The attention economy

Most just click on things, join this, go there, add that, subscribe to this, install a new app. It doesn't register that hackers can simply access large databases and get a lot of information about you. If something is too hard - such as signing in, users won't even bother to wait a couple of minutes to sign in.

For that reason you have to decide what type of audience you are building your software for and try to explain why you have taken this approach. Even a couple of paragraphs explaining why you have done this is too much for most people.

What is the need for Zero-Knowledge Trust security?

We will outline multiple reasons including a case study, a real example that happened to our platform.

Deplatforming or service cessation - the reason to look to Zero Knowledge Trust security

Deplatforming sadly infers that the individual that was deplatformed must have done something wrong. This is so often not the case. In our case, we have been unfairly treated and suffered reputational loss, and this occurs to businesses and individuals constantly.

Our X Account is still suspended. Why? We were discussing different marketing approaches and included a Nostr endpoint which was nothing more than a website address where data can be publicly transmitted to. Twitter decided that this was a harmful link and our account is permanently blocked. In the past we have had websites which use different identity providers including X and this means that if users suffer similar deplatforming they would no longer be able to use our services.

We appealed this ban on countless occasions and we're always given an AI reply.

OAuth is an authentication service provided by large technology companies. There are mutual benefits for both the company and the users. The companies can maintain awareness of their brand, better control security when users connect with their services and it is easier for these companies to link their own applications and services to their users. Users benefits by using a single account to access many services we have confidence that the OAuth provider is has far more resources to control what data is permitted to be used by independent service providers.

Aside from our obvious gripes with identity providers, for independent service providers - OAuth can become a nightmare if users are connecting to your services through these providers. OAuth changes and a large section of your user-base can no longer access services provided by your platform.

Emails and passwords

The minute you store passwords there is an extra burden on the potential of security breaches. We just don't know if users are sensible enough to generate a unique password for every service they consume. It can become quite a universe to do this and So what we sometimes do is for very simple sites without much of a digital footprint, we may just use a fairly standard password. As sites get more sensitive, definitely use a password manager.

From a service providers perspective, providing passwords and facilities to change them is an overhead which invariably becomes a problem. For this reason we introduced the idea of e-mail account based authentication only but even this in itself is not necessarily ideal. You can recreate 2 factor 3 factor authentication by having an e-mail account on different devices for example. You can install different domain emails.

E-mail and passwords are not an ideal approach

Protecting the service provider

As strange as it may sound, service providers themselves need protecting. With ever increasing regulations around data protection we have to ask a fundamental question - do we need to know who our user is? In most circumstances, the answer is no. We can also ask, so we know who our user is but do we need their security details to access their own data? Again, the answer is a resounding no.

This is where common sense can be applied. Many service providers are providing fairly low cost subscription services and with the cost being so low, if they were playing in digital assets - there would be little need to worry about anti money laundering, know your customer, etc. all funds are controlled on exchange, our software simply orchestrates trades on our behalf.

As an example, is it truly the case that criminals are going to subscribe to cryptocurrency data for X$ a month? Does all software need to know who the user is?

How we are implementing Zero-Knowledge Trust security

Background on ZKT

We have been working on the productionisation of a dedicated automated cryptocurrency trading solution. A big amounts of this work is more to do with the building our services and thinking about how we can secure customers data. Once your API key for a portfolio is exposed, all the funds in that account can be taken.

We explored many centralised security providers, and can summarise the challenges as following;
• Certain providers are more enterprise based - we would have to take ownership of maintaining accounts for customers which whilst there are ways to isolate keys, brings into question whether we are without knowledge of the customers keys?
• Many providers whilst offering a basic free version are not fit for purpose
• Other providers still have that deplatforming potential feel to them
• All centralised secure providers was a huge learn for anyone wanting to try to allow their customers to own their own data
• A big leap of faith. We spent quite a bit of time exploring Hashicorp, we think it's an excellent technology. But having a full understanding as to how it can meet our needs definitely quite a significant investment. This is not just Hashicorp, Azure, AWS and others.
• It is worth highlighting that different security providers have completely different ways of providing authorization and your software will have to reflect their specific approaches

Our specific requirements

The trading exchange

Typical approach is users add one or more portfolios and set up a access to them. The user then adds these key to different software for performing automated trading.

Our Dedicated Trading Platform

Most will buy access to run a cloud instance of our trading software. We have multiple applications on there for interacting with the exchange, storing data, and managing trading rules. We also have a trade the management portal for setting up rules and managing services on the cloud instance.

How users will pay for our services

Users will pay a setup fee, and an ongoing subscription. Users will need to be a member on a site and currently this is unfortunately going to still have to use the e-mail based verification approach. We can currently accept payments through Coinbase but are looking to other wallet providers for this.

Once in receipt of a valid payment we will provision a cloud based instance.

Initial Onboarding

Once the user has been provisioned access to the trading platform after paying, they will receive a confirmation e-mail. This e-mail will contain the following information;
• The importance of not simply running through the steps straight off. The importance of secure API access is important and missing steps can cause risks
• Basic fail-safes, break-glass approaches to quickly lock down access to their API
• We explain that most setup is via the web application they will be provisioned but that some external setup is required
• The importance of recycling API keys
• If you use the importance of using password managers for saving their security information securely
• The details of the website where they manage their trading - it is individual
• An explanation that they need to sign in with Crypto Statto plus tokens first time setup
• Details on how to set up a Read only portfolio API Key on the Centralised Exchange (CET)
• A brief overview/guide on how the automated trading software interacts with the CET's API and their respective portfolios, including an explanation of different permissions
• A basic process flow of setting up the dedicated software to access the CET's API
• Instructions of the independent cloud based security portal our software interacts with, how they will add their internal portfolio ideas and API security information

The fun part - Zero Knowledge Trust with Nostr

Most think that Nostr is just another Twitter/X replacement. It is not. The main differences we see are;

• Key only access. Nostr gives you a public key and private key to sign in
• Censorship Resistant content. Relay based decentralised content hosting and sharing. Whilst a relay can decide what it wishes to show, your data is permanently stored and distributed
• Private key generation - a host of different libraries exist permitting you to generate your own keys
• Ability to set up private message channels where you issue keys to your users on your own relay
• New functionality being added - a very interesting piece of work is "Ghost Untraceable Digital Dissident, Cold Root identity". The aim of this is "Implementation of cold root keys deterministic epoch keys, and lineage proofs for Nostr". Quite simply, a root application can generate new keys which can be tracked back to a cold root key. This could be a good way to implement sessions

Nostr Zero Knowledge Trust implementation within Crypto Statto

This is a summary rather than a detailed coverage of the methodology;

• Use a client to generate a private and public key for a customer (We could issue this to the customer but that would introduce breaking Zero Knowledge Trust)
• Verify that token on our Secure server
• Generate an encryption key (We err towards the Bech32 version, but to be decided)
• The user can enter secure data within the client
• Pass that data to our secure data and encrypt it
• Forward this onto other servers, this acts as off-site memory stores of encrypted data
• Each customer has their own stores, this prevents data breaches for all customers if the server is compromised
• Forward the Encryption Key from the client only to the server where decryption is needed
• Only maintain sensitive data in memory

Please note, the above is not an exact implementation and is not advice on how to do Zero Knowledge Trust.

Other Providers

Our underlying security software is designed to allow us to plug more providers in, for example, Metamask.

Conclusions on Zero Knowledge Trust

Zero Knowledge Trust gives developers far more flexibility at securing important data without having to store data and the key to decrypt it themselves. A major challenge for smaller service providers is risks from server hacks, exposing all user's security. For Crypto Statto, we go to great pains to avoid passwords on our main website. Sure, somebody could hack our server, download our database and eventually brute force encrypted keys to find out… email addresses that could be anonymised use our website to… view cryptocurrency reports. Hardly ground-breaking doxing information?

Taking this a step further, once we have provisioned access to our dedicated trading software, why do we want to go through the overhead of storing sensitive data on our servers in plain-text format? Why not use a well-used enterprise but open source protocol to let users generate and retain data for encrypting data securely?

Our technology is capable of running in containers and on multiple servers. We will have a React-Client ready after Xmas, which whilst being tailored to our own trading software, this technology is fully agnostic.

Feel free to reach out at Info Rhino or Crypto Statto to find out more.

Written with StackEdit.