By: Carlo Gutierrez and Alex Khizhniak, Altoros

A new document explains how blockchain transactions can be verified without having to reveal the details. Some of the model’s implementations include Idemix and Hyperledger Indy.

Transparency is considered by many to be one of blockchain’s most important traits. However, there are businesses, such as those in finance, which deal with sensitive information. In these situations, transparency takes a step behind privacy. For organizations operating with confidential information, implementing blockchain transactions with zero-knowledge proof (ZKP) is a solution to consider.

Altoros, a General Member of Hyperledger and an expert in blockchain development and training, has released a research paper exploring how to ensure privacy while still providing transparency on a blockchain.

Who can benefit from ZKP?

In a nutshell, ZKP is a method in cryptography where a prover can convince a verifier that it knows a secret value, without actually disclosing any information apart from the fact that it knows the secret value. While this requires some input from the verifier (e.g., challenging a response), there is also a form of this model called noninteractive ZKP, which does not require such an interaction between the two parties.

Avoiding linkability between certificates using ZKP protocols such as Idemix (Image credit)

Applications that benefit from ZKP are those that require a measure of data privacy. Some of these example applications include:

Authentication systems. The development of ZKP was inspired by authentication systems, where one party needed to prove its identity to a second party through some secret information, but without revealing the secret altogether.

Anonymous systems. ZKP can enable blockchain transactions to be validated without the need to reveal the identity of the users making a transaction.

Confidential systems. Similar to anonymous systems, ZKP can instead be used to validate blockchain transactions without revealing pertinent information, such as financial details.

ZKP implementations: Idemix and Hyperledger

In Hyperledger Fabric, privacy-preserving authentication and transfer or certified attributes can be done using Identity Mixer (Idemix), a ZKP-based cryptographic protocol. Its implementation consists of the three components:

• A core Idemix cryptopackage (in Golang), which implements basic cryptographic algorithms (key generation, signing, verification, and zero-knowledge proofs)

• MSP implementation for signing and verifying transactions using the Identity Mixer cryptopackage

• A CA service for issuing ECert credentials using the Identity Mixer cryptopackage

The Idemix architecture within Hyperledger Fabric

This combination provides:

• anonymity (sending transactions without having to reveal your identity)

• unlinkability (sending multiple transactions without revealing that all the transactions come from the same source)

Based on Idemix, the Hyperledger Indy project was built for managing decentralized, independent digital identity. It utilizes the so-called Indy-anoncreds to cryptographically secure credentials. Just a couple of days ago, it was announced that The Hyperledger Technical Steering Committee (TSC) had approved Indy to graduate from incubation to the active status.

For more details on ZKP, the zkSNARK protocol, and noninteractive ZKP implementations (such as Idemix and Indy), check out the full research paper.

In Canada, starting a new business can be like navigating a maze with three levels: local, provincial, and federal. A helpful checklist on starting a business in Canada offers 60+ links to explore. All this red tape frustrates entrepreneurs and governments alike.

To lighten that burden, teams from the governments of British Columbia (BC), Ontario and Canada have started an ambitious project to fight red tape using decentralized identities and trusted credentials. They are jointly building the Verifiable Organizations Network (VON), to provide an open source software stack that helps business people establish trusted and enduring digital identities and speed up applying for permits and licenses from government agencies.

The first project to emerge is OrgBook BC, an online directory that makes finding authentic and authoritative data about companies faster and easier. Launched in January of 2019, it is designed to reduce the time to do due diligence on a new supplier or client from hours down to a few seconds.

Of course the path to this launch included a number of key development challenges, strategic technology choices and partnership across governments and the larger Hyperledger community. For more on all of these steps, check out this detailed case study.

Now that OrgBook BC is live, the VON goals are expanding the applications, growing the footprint and encouraging more jurisdictions to use the software stack until the network effect takes hold. To get the larger developer and business community engaged, the team is hosting BootCampBC as part of #BCTechSummit. The Honourable Jinny Sims, Minister of Citizens’ Services and MLA for Surrey-Panorama, will be opening the event, underscoring the government’s commitment to driving the growth and adoption of VON.

BootcampBC, hosted by technology leaders from Hyperledger Indy, Verifiable Organizations Network (VON) and the Sovrin Foundation, will cover the concepts of self-sovereign identity and guide participants through building their own Hyperledger Indy agent to verify and issue verifiable credentials using VON’s technology.

The Scope and Limits of Indy’s Privacy Tech

Guest post: Daniel Hardman, Evernym

Privacy is a hot topic in blockchain circles–and across the entire digital landscape. GDPR, ePrivacy, and similar regulatory regimes have the world thinking hard and smart. Modern systems must bake privacy into their DNA; it can’t be bolted on after-the-fact. I’ve written elsewhere about why this is true, and how it must be done–and I’ve spent the last couple years helping Hyperledger Indy embody all the privacy goodness I know. I’m encouraged to hear a swelling chorus of blockchain practitioners opine that certain things must NOT go on a blockchain.

Perhaps you have heard a claim that Indy “solves” privacy. Or perhaps you’ve seen skeptics roll their eyes, muttering about how we’re all going to be correlated by the surveillance state, no matter what we do.

The truth is that both of these perspectives distort reality. Indy does offer some wonderful features to aid privacy, and these features matter! But institutions are certainly going to know some things about us, no matter what Indy does. Indy can minimize this in exciting ways. Nonetheless, what privacy we have, now or in the future, will emerge from a combination of technology, social and legal constructs, market forces, and human behavior; it can’t be trivialized as a tech problem.

What “Privacy Tech” Are We Talking About?

Today, Hyperledger Indy’s approach to privacy includes elliptic curve cryptography, pairwise DIDs, semi-trusted agents, agent-to-agent communication using techniques such as libsodium’s sealed box and authenticated encryption, zero-knowledge proofs, a separation between credentials and proofs, privacy-preserving credential revocation features, an affinity for data and key storage at the edge, and a carefully constructed wallet interface that manages personal secrets with industry best practices. In addition, privacy-preserving agent (device) revocation has been demonstrated as a proof of concept.

Indy’s roadmap includes additional privacy-enhancing features such as a user-friendly SSI tool (mobile app) with smart and safe defaults, microledgers, sophisticated policy and/or AI for agents, mix networks for transaction submitting and agent routing, and so forth.

Some of these technologies exist in other identity technologies, but Indy combines more of them, in far more powerful ways, than any similar technology I know.

What All This Tech Does NOT Deliver

Except for people who live in remote, technology-scarce  places, all of us are constantly observed and recorded. Google maps may have a picture of our front door; cell phone towers track the location of our mobile devices; credit card companies see what we spend; closed-circuit cameras watch us on the road or subway.

In such an environment, much will be known about us, even if we use Indy to prove things in zero knowledge. And, if we choose to use Indy to disclose something identifying–our email or phone number or name+birthdate, for example–then the disclosing interaction is correlatable to a much bigger digital footprint, no matter what fancy math did the proving. Even less perfect correlators like first name + fuzzy place + fuzzy time may correlate us, given sufficient context.

It might be tempting to say, then, that there’s no point to Indy’s elaborate privacy posture. But there is more to the story.

What Hyperledger Indy Privacy DOES Deliver

Hyperledger Indy allows you to construct interactions where the degree of disclosure is explicit and minimal–much smaller than what was previously possible. Nothing about the mechanics of connecting, talking, or proving in Indy is leaky with respect to privacy; vulnerabilities that emerge must come from the broader context. No other technology takes this minimization as far as Indy does, and no other technology separates interactions from one another as carefully. If privacy problems are like a biohazard, Indy is the world’s most vocal champion of wearing gloves and using a sharps container for needles–and it provides the world’s best latex and disinfectants.

Of course, this does not give perfect protection. Like a needle stick, mistakes can ruin Indy’s carefully sanitized interactions, and contamination is always a possibility. In 2017, the layouts of US army bases in some of the most dangerous locations in the world were compromised because soldiers had been using the Strava running app to track where they exercised (https://wapo.st/2J6DQqU). If this can happen when stakes are so high, and when the organization is as careful as a sophisticated army, then similar fiascos will undoubtedly occur, both with and without Indy technology, for the foreseeable future. These are serious problems that are not to be underestimated.

Despite the imperfect guarantees, doctors consider it worthwhile–even vital–to wear gloves. And despite risk, Indy’s privacy tech can deliver real value, if we are careful about constraining behavior and understanding use cases. Any interaction that does not leak is a tiny bit of personal, private space–and chaining such interactions together can accrue significant benefits. Indy makes it possible to prequalify for a loan at a thousand banks, in a way that proves credit worthiness, income, and citizenship, without forfeiting privacy. Used correctly, it can insulate cautious whistleblowers; it can enable secure, private voting; it can make online dating safer. Many other use cases exist. In each situation, we must carefully assess privacy beyond the narrow context of Indy’s proving mechanics. Gloves are less helpful when a disease vector is airborne; the government still needs to know who you are when you pay your taxes.

Intentions And Incentives

Besides discussing what protections Hyperledger Indy offers on the technical level, and what ways there might be to defeat such protections, we can also make an argument that architectures, algorithms, data models, and cryptography always carry a certain “intention” towards the parties we interact with. In our case, this intention is to maintain the individual’s privacy, sovereignty, etc. Whether or not the technology can strictly enforce this intention, or to what extent, is an important question, but not the only argument for building it in a certain way.

If we use pairwise DIDs and zero-knowledge proofs, the message is clearly “don’t try to correlate me,” even if you could find a way to do it if you try hard enough. An HTTP Do-Not-Track header says “do not track me,” but it doesn’t offer any actual protection from tracking. The VRM community has been talking about user-defined terms for a long time. In a relationship, you can express “don’t use my data for advertising,” or “delete my data after 14 days,” or “use my data for research, but not commercially.”

Simply expressing these intentions in code and architecture has value by itself. It bears a message that privacy and sovereignty “should be honored,” even if it cannot always be guaranteed technically that it will be. Over time, we expect that through regulation, trust frameworks, reputation, and similar mechanisms, not honoring such intentions will be discouraged. Of course we must always communicate clearly the limits of intentions and guarantees, lest we create a false sense of security that can lead to severe consequences.

One of the main reasons for the growth of Internet’s re-decentralization movement (Diaspora, Bitcoin, etc.) was not only to achieve more privacy and independence, but also to build architectures that better mirror the way we want society to work in the real world (not client/service aka. master/slave). At the same time, the point of view that “technology is neutral” is getting less prevalent, being more and more replaced by an assumption that “technology has built-in values.” From this perspective, privacy tech is valuable not only as a technical defensive mechanism, but also to make a point, to convey an intention.

Importantly, Indy’s technology also enables the transformation of privacy incentives. Companies that once stored PII can now store an opaque identifier for a customer, and contact the customer’s agent to learn more–then throw away the data after they use it. This has the potential to eliminate many centralized data troves as hacking targets, and it empowers people instead of impersonal and conflicted corporate guardians. Indy also provides meaningful advances in the world’s answers to privacy regimes like GDPR. We believe that in the future, social, software, and legal constructs will evolve to take advantage of the privacy features offered by Hyperledger Indy, and that this will lead to ever more creative types of business models and digital interactions not possible before.