Achieve Fully Decentralized End to End encryption meeting via Blockchain

Achieve Fully Decentralized End to End encryption meeting via Blockchain

Achieve Fully Decentralized End to End encryption

meeting via Blockchain

Zoom meeting is an online platform for video conferences. Though it already took some security steps, it is capable of  monitoring users data for centralizing the system. Thereby, to solve the privacy problem, Zoom acquired Keybase so that Keybase’s team can help it to build end-to-end encryption meetings while remaining Zoom’s current scalability and high-performance. Nonetheless, according to the latest released Zoom’s whitepaper, even with the new design of E2E(end to end) encryption meeting, the security threats can’t be erased completely since the new design is not fully decentralized. In this paper, we introduce a fully decentralized design of E2E encryption meeting via blockchain technology. With this new design, Zoom’s E2E meeting privacy can be further improved.

 

  1. INTRODUCTION

Zoom is a well-known company for providing scalable and secure solutions for long-distance group video or voice meeting solutions. Also, its product is very easy to use, with a meeting id and password(optional), users can access a meeting by Zoom client, web browser, or phone call on various devices. Zoom has gained a large number of users due to these properties. Especially during the outbreak of the COVID-19 pandemic, more and more people choose to work at home to avoid human contact and Zoom’s online group meeting obviously is an ideal solution for them. If a Zoom’s server is compromised, a hacker can obtain all the meeting's private messages. To solve the privacy issue, Zoom acquired Keybase in the early of this year. Since Keybase has an experienced team in cryptography and privacy solution, this acquisition marks a key step for Zoom as it attempts to accomplish the creation of a truly private video communications platform that can scale to hundreds of millions of participants, while also having the flexibility to support Zoom’s wide variety of uses.

 

  1. BASIC DEFINITIONS AND SECURITY MODEL

PK/SK PK: a.k.a Public key for a public key cryptography algorithm and is open for anyone.

SK: a.k.a Secret key or Private key, this key is kept by the user privately. PK/SK represents a public key pair.

Meeting participants: Under the authorization of the meeting leader, participants who can enter a meeting and access meeting content.

Meeting leader: One meeting participant who initiates the meeting and will be considered the meeting “leader”.

Adversary: A malicious user who tries to break the E2E encryption meeting, he can view all the public information published on blockchain and he may monitor, intercept, and modify network traffic among meeting participants.

Blockchain: Blockchain is a technology to achieve consensus on a single data value or a single state among peers in an open untrusted network. The name ‘blockchain’ comes from the fact that the basic data structure of blockchain is made up of a set of blocks. A block is made up of a set of transactions that happened in a short period. The most obvious feature of blockchain is decentralization.

Identity Blockchain: A blockchain that records meeting participants‘ identity information and mapping relations among meeting participant, device, and device’s identity public key.

Meeting blockchain: A blockchain which is used to publish the public information of a meeting which includes: meetingID, all participants’ meeting requests, meeting leader, participants’ public keys etc.

E2E encryption meeting: First of all, in meeting impersonation attacks: A malicious but otherwise authorized meeting participant colluding with other meeting-related parties can masquerade as another authorized meeting participant.

Secondly, Metadata and traffic analysis: Even for end-to-end encrypted meetings, insiders and outsiders can learn details about meeting duration, meeting bandwidth, data streaming patterns, participant lists, and IP addresses.

Thirdly, denial of service, this a very common attack. Attackers can disrupt the message routing and delivering, key distribution etc to cause the unavailability of the E2E encryption meeting. Security goals Against these adversaries colluding or working independently, an E2E meeting protocol design seeks the following security goals:

Confidentiality: Only authorized meeting participants should have access to meeting audio and video streams. People removed from a meeting should have no further access after their expulsions.

Integrity: Those who are not allowed into a meeting should have no ability to corrupt the content of a meeting.

Availability: The E2E encryption meeting service will always be available for all meeting participants. The adversary can’t disrupt the message routing, delivering, key exchange, meeting information etc.

 

III. A BRIEF INTRODUCTION OF ZOOM E2E ENCRYPTION MEETING PROTOCOL

Phase I: Client Key Management

In the first phase, each user’s Zoom device will generate a long-lived pk/sk identity key pair and the central Zoom server will maintain the mapping relation among the meeting participant‘s UserID->DeviceID->identity pk. With identity key pair and randomly generated ephemeral pk/sk key pair, users’ devices can negotiate and exchange session keys without a trustful central server. Public information needed for the meeting’s key negotiation and exchange process is published on a reliable signaling channel which is called ”bulletin board” and it is maintained by Zoom servers.

Phase II: Identity

To avoid Zoom server maliciously altering the mapping between meeting participant’s UserID to public keys, in this phase, Zoom introduces two parallel mechanisms. Firstly, Zoom introduces SSO and allows SSO IDP to sign a mapping of a Zoom public key to an SSO identity. Zoom can not fake this identity Unless the SSO or the IDP has a flaw. Second, Zoom allows users to track contacts’ keys across meetings.

Phase III: Transparency Tree

In the third phase, Zoom implements a mechanism to force Zoom servers (and SSO providers) to sign and immutably store any keys that Zoom claims belong to a specific user, forcing Zoom to provide a consistent reply to all clients about these claims. Each client will periodically audit the keys that are being advertised for their own account and surface new additions to the user.

 

Phase IV: Real-Time Security

In Phase IV, to avoid a malicious Zoom server add a new ’ghost’ device for the attacked user who does not have IDP vouch for his identity and fake this user to enter a meeting. Zoom will force a user to sign new devices with existing devices and use an SSO IDP to reinforce device additions, or delegate to his local IT manager.

 

  1. Potential security threats
  1. First of all, user and his devices’ identities authentication heavily relies on the SSO IDP and Zoom which are both central.
  2. The append-only property of the ZTT tree which is used to record mapping relations among meeting participant’s UserID->DeviceID->PK is ensured by Zoom and external auditors which are also not fully decentralized.
  3. Even though Zoom removed the role of distributing meeting keys, publishing public meeting information on bulletin boards and delivering messages among users is still done by Zoom. Those information could be altered by a malicious Zoom server and cause denial of service.
  4. Even though it has no access to secret key material or unencrypted meeting contents and no longer plays a role in distributing initial shared meeting encryption key among participants, Zoom still controls the basic infrastructures.
  1. DECENTRALIZED END TO END ENCRYPTION MEETING
  2. Identity

In this phase, all the meeting participants will generate an identity key pair PK/SK on their own devices. Then they will upload the mapping relation among UserID->DeviceID->PK to identity blockchain by committing an identity transaction.

  1. Meeting Information Publish

First of all, the meeting leader needs to generate an ephemeral PK/SK key pair for DH key exchange in the ”Meeting Key Exchange” process with other meeting participants.

  1. Meeting Request Generation

First of all, after obtaining the Meeting ID, the meeting participant generates an ephemeral PK/SK key pair which later will be used for key exchange.

  1. Meeting Key Generation

After verifying all the meeting requests, the meeting leader will generate a 32 bytes meeting key M K which later will be used for encrypting the meeting content.

 

  1. CONCLUSION

In this paper, we proposed a new fully decentralized E2E encryption meeting design to enhance the popular Zoom’s security. At a high level, the approach is very intuitive, Zoom introduces the E2E encryption design to diminish the status of Zoom’s infrastructures in providing online meeting service and enhance Zoom’s meeting’s security. But Zoom’s new design can’t achieve full decentralization. Thereby, by introducing the blockchain technology, our new design can help Zoom achieving full decentralization and furthermore enhances its security by eliminating the security threats caused by central parties such as Zoom infrastructures, ZTT auditors, SSO IDP, etc

Files

What's Your Reaction?

like
0
dislike
0
love
0
funny
0
angry
0
sad
0
wow
0