Zero Knowledge Proof Group Authorization protocol for Swarms

GRIDNET OS - Development
1

Something very exciting has been going recently, and it has to do with Swarms - a technology specific to GRIDNET OS and which is to allow for decentralized, cross-browser and end-to-end encrypted communication. Including high-definition audio and video transmission, including screen sharing.

All the data flows are to be incentivized through the system intrinsic crypto asset when and as needed.

The underlying idea is for the technology to be available to third-party developers through easy-to-use programming interfaces (APIs) available straight from JavaScript.

Everything should be as automatic and as autonomous as it gets.

We believe to have arrived at a satisfactory level of such a briefly defined functionality set. The technology is already available to you with the today’s update (now holds true only for the official nodes as GRIDNET Core 1.1.1 has not been publicly released, yet - as an Installer, that is).

OK, but the technology has been around in GRIDNET OS for quite some time already. So what’s the deal?

Well, we’ve improved it like a lot.

First off, WebRTC signaling is now fully decentralized. I’ll be extending on this later on.

Second, we’ve introduced groundbreaking Zero Knowledge Proof Group authorization protocol, which has been both conceived and implemented by our team from scratch. The TLA+ simulations and symbolic flow analysis all concluded its soundness. While I am in no position to be speaking about the underlying cryptographic constructs (@Major) me and my sub-team have been heavily involved in JavaScript implementations of it.

You may expect a dedicated article at the GRIDNET Magazine regarding this, also there’s expected a dedicated research paper tackling the ZKP protocol.

I’ll let others discuss the details and rationale for why such a protocol was needed in the first place.

For now, do know that the technology is already available through both the eMeeting and Whiteboard UI dApps accessible at https://test.gridnet.org

Feel free to take these for a spin and I’ll be extending on this post / thread.

3 Likes
2

First, we need to understand some of the basics.

What a Swarm is and what does it allow for. Instance of a Swarm allows for group connectivity in an untrusted environment. Untrusted? How so?

Imagine, we’ve got multiple peers willing to have a group meeting. Usually there are some computers either acting as intermediaries - meaning as full-blown servers, doing matching of peers and retransmitting data received from peer A to all the other peers involved. Usually, such a provider (Facebook, Skype etc.) is also able to see all the data passing by between participants.

We do not want that. We want the entire mechanism to be both decentralized - so that nobody ever has control over its operations, and - we want the service to be end-to-end encrypted at all times. So whenever another party is involved in data retransmissions, it has no way of knowing what these data packets actually contain.

As far as we are aware, the technology which we’ve been working on covers all these bases and it is the first technology of such a kind for cross-browser communication.

And indeed. What does it mean? Let us say a few words about the underlying WebRTC technology first, shall we?

WebRTC is now a standard for cross-browser communication, implemented by all the major players. Yes, your web-browser supports it.

So what’s the deal with signaling?

First off, as the above referenced Wikipedia page states:

The WebRTC API includes no provisions for signaling , that is discovering peers to connect to and determine how to establish connections among them.

In short - even though WebRTC may be used very effectively for cross-browser communication, it does not provide two things:

  • it does not provide ‘signaling’ protocol of any sort.

  • WebRTC technology implies use of a ‘server’ which would take care of passing the ‘signaling’ datagrams between peers.

The lack of a signaling protocol is both good and bad. On one hand, developer has freedom of choosing /implementing the mechanics by himself on the other - that’s something that needs to be taken care of.

When you think of it, had it not been the case, and had WebRTC enforced a certain kind of signaling protocol, we would never be able to implement Swarms technology.

Now, for the second - the need for a server. WebRTC is an API. It is accessible from JavaScript. Once signaling is needed (and it always is) , the need arises for a signaling server.

Oh, oh… but who’s to be operating that ‘signaling server’? Under whose control it’s gonna be?

Now we begin to see more and more clearly… the one who operates the signaling server, he is going to end up wielding power in his hands.

How? Show the signaling server go down - the entire service goes down.

Should a user be behind a firewall, an ‘administrator’ could cut the user out from accessing the service as well - Easily.

All other things held constant, relying on a single party to provide all the signaling services - Let it be for free or not wouldn’t be the most desirable form of making things work in a supposedly decentralized environment.

Decentralized signaling is needed also from a technical perspective.

Imagine, as peers connect to multiple nodes (and they do - as both the bootloader and JavaScript-based VM Context toss nodes to even serve UI components from nodes discovered through Kademlia), then - each and every peer might end up being connected to a different ‘signaling node’.

What’s wrong with that? You might ask…

Well, we were after having group conversations, remember?

So, if Allice ends-up connected to signaling node N1 and Bob ends up connected to signaling node N2, how are the signaling datagrams be exchanged between Allice and Bob if, now fathom - N1 is entirely not aware of Bob and N2 is completely unaware of Allice to begin with.

Indeed, connections would be effectively established only among peers connected to the very same signaling node/server. There would be no communication between peers connected to different signaling nodes. Period.

The big news is that we have managed to change all that. We have made signaling datagrams traverse signaling node boundaries. Now, N1 would communicate to N2 all Swarm members he is aware of, and vice versa. As one may imagine, it is significantly more complicated than that, though.

Signaling nodes exchange most of the SDP datagrams when and as needed. That also holds true for the exchange of ICE candidates.

So, with our technology, Allice and Bob do not need to worry whether they end up being connected to same signaling node or not. Or whether a given signaling node is available from behind of a firewall, they happen to be obstructed by.

1 Like
3

Thank you @PauliX and @vega4 , you’ve done a wonderful job - introducing all of us to some of the underlying problems and how (at least from a high viewpoint) we’ve managed to solve these at least highlighting that we actually did.

What needs to be emphasized is that we have made these mechanics easily available to JavaScript developers. A developer ‘joins a swarm’ by interacting with the ⋮⋮⋮ Context, and I mean it - he invokes a single joinSwarm() method - providing its identifier, then he signs up for some of the events as desires -and that’s it.

The developer never has to choose a signaling server, developers might not ever be aware of what WebRTC actually is. There is no need for that. Our APIs guide her by hand.

The Swarms API takes care of accessing and releasing hardware handles to microphone / camera (so whenever an UI dApp exists, the ⋮⋮⋮ System keeps track of all the apps taking use of camera, and when there are none - it makes a decision to release the underlying hardware asset). Same goes for a microphone, the same goes for a handle to shared screen or a particular native window.

Whenever a new peer joins a Swarm, the member is notified through invocation of a callback function she has provided. Invocation of the callback function contains a reference to a Swam-Connection, the new peer’s identifier, whether the peer had been already authenticated or not etc, etc. - all passed into the function as en Event parameter.

Developer may interact with an entire Swarm or particular participants. It holds true for both notifications (through callback functions) and for actuators - such as functions used for dispatchment of data.

In fact, it gets way more sophisticated than that. Way more. How?

To fathom that, imagine that the Swarms API contains full-blows implementation of virtual (sick!) microphone and camera devices. Why on earth would something like that be required?

Security. Ease of use. Agility. It would take lots of effort to tackle all the miniscule peculiarities.

But I’ve already mentioned the virtual devices, so let us continue.

We employ virtual devices to allow for dummy tracks.

Why dummy tracks are needed? First off, WebRTC implementations are not perfect. The technology is new. With Swarms we cover up and compensate for all these downsides and shortcomings. We build yet another layer atop of what is available.

So whenever client UI dApp wills to switch video streams or audio tracks, we have it covered. We would establish connectivity based on dummy audio/video tracks, - provided by virtual devices - negotiate quality based on these and be ready to switch to actual data streams whenever desired, yet again - by the client UI dApp.

And yet again, it goes way deeper than that. The rabbit after having gone deep into its burrow… lurks straight into our eyes and whispers - “(…) privacy (…) authorization (…)”

2 Likes
4

WebRTC is end-to-end encrypted by default. In fact, it may be difficult to disable this property.

But then, WebRTC does not provide any mechanics for group conversations or group data-streams.

Everything is point-to-point, and that’s it.

Hold on, wait a sec. But we were after having group conversations, with high-definition audio/video etc. weren’t we?

Right.

And there were no ‘servers’ to be involved, remember?

Usually (Facebook, Skype etc.) they take care of all the authorization mechanics. Users are either logged on to the accounts of theirs or not. Either they are granted participation privileges or not. Such providers control everything. User credentials (logins, images of passwords) these are all stored on servers being under their control.

How do we achieve group privacy in an untrusted environment? How do we allow anyone to join, anyone who… knows a password?

There is no easy answer to this question. It is not enough for peers to perform mutual authentication on the password by simply exchanging the password as - that would make the other peer know the password to begin with. And the other peer might be Eve -an attacker simply lurking to get to know the password.

We cannot exchange images of passwords, as even though that would not reveal these - it would be opening up the system to reply attacks.

So what we did was - we have conceived, researched, validated and implemented - a Zero Knowledge Proof authorization protocol. In short, through it peers prove among themselves knowledge of a pre-shared secret, without actually leaking any information about it.

Should you wish to get to know more about Zero Knowledge Proof protocols here’s a place to start.

@PauliX would you care explaining how these mechanics are manifested within of the User Interface?

For now, what’s important is to know that each group conversation is protected by the identifier of a particular meeting. That is by default. So whenever you enter a meeting ID it is assumed as a secret. Not even signaling servers get to know this value. You share Meeting ID only with those who are supposed to join. It should be impossible for others to effectively participate on your group conversation or get to know any information in regard to data being exchanged among participants who know the Meeting’s identifier.

That’s once scenario.

The other scenario is when users want the Meeting Identifier to be publicly known. For example, by putting it on a website or other media channel. In such a case, users still can still benefit from privacy by using a pre-shared secret in conjunction with our unique Zero Knowledge Proof protocol.

Users are assumed to know the pre-shared secret. They provide the secret to the eMeeting UI dApp (which under the hood invoked certain methods of the Swarms API), but the secret is never transmitted, in any form. And what is transmitted is not susceptible to reply attacks in any form.

Thus, yet again, when Eve - willing to discover a pre-shared-key comes along and tries to persuade Bob to reveal the secret - presumably as she would insist to Bob - to verify whether Bob knows it in the first place - thanks to our Zero Knowledge Proof authorization protocol, Bob would be able to prove its possession but Eve would not get to know anything about it. Also, she would be able to confirm it only had she known it to begin with.

1 Like
5

Very good work indeed ,I can see much progress is being made since last I visited the OS.

6

Once Core 1.1.1 becomes available for download, it definitely is going to be the biggest ‘update’ we’ve ever released, since Core software became publicly available, that’s for sure.

7

I am looking forward to it, any idea on timeframe for that ?

8

This very week, maybe. We would like to make it this very week for multiple reasons. That’s what we know.

9

Wonderful ,Thanks for the headsup. :crossed_fingers:

10

and it turns out we are headed for the midst of April :blush:

11

Leave the work; you’ve done enough, come along and have some fun (…) good papa awaits.

12

A notification just woke me up. Major, why so shy; let it be… I literally LoLed aloud :melting_face: Reporting Major! Me - already packed!

13

So be it then :slightly_smiling_face: :pray:

14

Most of us are currently on our ~yearly in-real-world meeting :partying_face:

15

Well in that case I hope that you all have some fun and laughs :smile:

2 Likes