The recent Optus data breach illustrates the honeypot effect resulting from the “hyper” centralisation of personal data.
By storing the personal information of millions of Australian customers in one place, on one local area network or within a single data centre, this company became the target of malicious hackers hoping to access valuable datasets by simply intruding into their system. The phenomenon is not new but has intensified in recent years. For example, Apple experienced a data breach in 2015, Alibaba and Facebook in 2019 and Linkedin in 2021. This is an important problem given that these personal data could allow anyone who gets them to impersonate a customer when interacting with private or even public services.
The Redbelly Network Solution
Redbelly Network operates in a regulated environment where users have credentials based on their personal information that allows them to access some financial services. The access to personal information should both be reliably stored and remain private. To this end, Redbelly combines a decentralised solution, which avoids the honeypot problem, with a verifiable secret-sharing scheme, which guarantees any user can retrieve their personal credentials from the networks. Redbelly removes the technical barriers that for years undermined mainstream blockchain adoption so you can build on a stable platform you trust.
Decentralisation
The solution to the honeypot problem is decentralisation. The user splits their secret information into chunks, such that each chunk taken individually does not reveal the secret. By distributing these chunks at different places/institutions, the only way for a hacker to learn the secret would be to hack all these places and retrieve enough chunks to solve the puzzle that leads to the secret. The cost the hacker has to pay to retrieve the secret becomes suddenly prohibitive: the hacker has to hack many places, and if few of them resist—say because they use a different OS/software that does not inherit the expected vulnerability—then all their efforts would be wasted. Hence, distributing the chunks reduces the attractiveness of hacking the secret.
A Simple Mathematical Example
For example, think about the secret that can be expressed mathematically as an equation, say y = 2x − 1, representing the set of points (x, y) located on a straight line as depicted in Figure 1. We can select three points located on this line whose coordinates (x, y) satisfy the equation, say (1, 1),(2, 3),(3, 5). One can verify that any of these points, say (2, 3), is on the line because x = 2 and y = 3 satisfy the equation y = 2x − 1 = 2(2) − 1 = 4 − 1 = 3. These points play the role of the chunks of the secret. If you have only one point, then this point does not tell you much about the secret since there are an infinite number of possible secrets that have this chunk. This is directly implied by the fact that an infinite number of lines cross a single point.
Retrieving Private Data
This decentralisation technique solves the honeypot problem. However, the owner of the secret may also want to retrieve its secret later on. This is typically needed when a user wants to prove to a new service provider that they have the credentials to access this service. If some chunks are inaccessible (e.g., the node hosting this chunk is unreliable), then the user will not be able to reconstruct the secret. We know since 1980, thanks to Pease, Shostak and Lamport that n nodes communicating over the internet cannot agree on the same value if n/3 or more of them are malicious. Fortunately, Redbelly is resilience optimal, this means that n of its governors will agree on the same block as long as less than n/3 of them are malicious. So let us see how one can retrieve the secret in the same model.
For the sake of simplicity, consider a very small network with only n=4 governors. Each user splits their secret into 4 chunks and distributes them to the 4 governors. As Redbelly is resilience optimal, it tolerates the presence of 1 malicious governor among the 4. It turns out that this single malicious governor cannot retrieve the secret: as we said above, a single point does not reveal much about the secret. The user cannot expect the malicious governor to give back the chunk, which is not a problem. The good news is that the user simply needs 2 points to retrieve the secret because any pair of distinct points is sufficient to retrieve their unique straight-line equation. So in the worst case, the user simply has to contact 3 governors to retrieve the secret.
Verifiable Secret Sharing
More generally, the user can request the chunks hosted by 2ƒ+1 governors by authenticating themselves to an identity provider where ƒ is the number of malicious (or faulty) governors. As 2ƒ+1 among these 2ƒ+1 governors are correct (neither malicious nor faulty), the user will be guaranteed to retrieve at least ƒ+1 chunks, which is sufficient to retrieve the secret. To access a service, the user simply has to prove that they have the necessary credentials without the service provider storing the secret. But how did Redbelly generalise this solution to the large networks in which it operates? The solution is called verifiable secret sharing: The simple example with the line can now be made arbitrarily more complex with polynomials. In particular, if we use a polynomial of degree ƒ as the secret, then we would need to retrieve ƒ+1 points to find the secret via polynomial interpolation, and no coalition retrieving ƒ points would be able to retrieve the secret.
To summarise, Redbelly Blockchain combines its inherent decentralisation property with a verifiable secret-sharing scheme in order to safely store and retrieve the personal information of its users while mitigating the risk of data breaches.
Redbelly Blockchain results from more than
