Sense Chat Tech

This post aims to provide deep technical explanations of how Sense Chat works. It is Part 1 of the updated whitepaper, which we lovingly call, the “Purple Paper.”

Purple Paper — Part 1: Sense Chat Tech | “A look inside.”

Introduction

Since the dawn of the Internet, communication has become increasingly interconnected. We communicate and collaborate across oceans and borders on a scale never seen before. The number of “free communication” platforms is truly astounding. However, these platforms are not truly free. As we have learned, our data is constantly being brokered by centralized platforms who are using our profiles, activities, and relationships for financial gain by selling that information to advertisers.

In addition, these platforms have become targets for attack. The personal information we thought was private is being exposed by massive data hacks. This is where blockchain enables a new level of data ownership through encryption and user-controlled encryption keys. The protection of our keys (and our data) does not need to be entrusted to a third party.

In 2009, the release of Bitcoin software enabled trustless, secure, peer-to-peer value transfer. For the first time, users of the internet were able to transact directly without any third parties to trust and verify. The “blockchain” of Bitcoin became a verified public record of transactions. The idea of trustless systems is the core concept that Bitcoin gifted to the world, and that blockchain-based applications seek to leverage.

Sense has built a protocol on the EOS blockchain for secure message transfer. This protocol leverages features inherent to EOS accounts to create identities for communication, knowledge sharing, and transactions.

Provably Secure

Perhaps the most important aspect of blockchain technology is the replacement of usernames and passwords stored on centralized servers with public keys stored on thousands of nodes. This makes any application inherently more secure.

Private keys are controlled completely by each user of Sense Chat. If a user creates an account or imports their key into the app, that key is securely stored in the device and never transmitted to any servers.

How Most Encrypted Chat Works Today

First a private and public key is generated for each user.

Alice has the keys:

Bob has similar keys:

Alice’s private keys are generated and saved on her phone, while Bob’s private keys are saved on his phone. The public keys are stored in a central server that identifies Alice and Bob.

When Alice wants to send a message to Bob, Alice takes Bob’s public key and signs it with her private key. She passes this signature to Bob, proving that she is in fact Alice.

Bob does the same thing, signing Alice’s public key, proving he is in fact Bob.

The combination of these two signatures is the “shared secret” which encrypts and decrypts all conversation between Alice and Bob. Since all of these public keys are stored on centralized servers, they cannot be viewed or verified or changed by the user.

The Problem and the Opportunity

In current messaging systems, the user has no control over the keys used for encryption. As important as keys are to the encryption of messages and data, the keys are not used for authenticating messaging accounts.

Instead of keys, most chat applications use your phone number or email to authenticate your account to your contacts and data. This exposes those messengers to the security weaknesses inherent to those systems. If someone gains control of your email and/or phone number, then they can access your messages.

Furthermore, impersonation is a common issue on many social and messaging platforms. Accounts and messages cannot be easily attributed or verified to belong to the actual person who it appears to be coming from.

Sense Chat

Sense Chat provides individuals an unparalleled level of empowerment in regard to the security of their communications.

Sense Chat uses a relatively simple technique for encrypting communication. Very simply, messages you send are encrypted with the public key of the recipient. That public key is stored on and referenced from the EOS Blockchain.

No easy workaround exists outside of the blockchain, because most users have no easy way to generate or transmit keys. The keys are useless outside of the app, therefore no one else cares to reference them, validate them, or store them in a public way that can be easily referenced.

There is no other chat application which utilizes blockchain in this way. One of our engineers, Angel Jose, conceptualized this technique and wrote a blog about how it works. Since that time we have improved upon the concept and increased the security of these methods and the size of the payloads.

Sense Chat users will be able to verify that each message was transmitted by the owner of the private key that is associated with the sending account. For example, to verify that the sender of a message (Alice) is in fact Alice. This works with the public / private key aspects of the EOS blockchain. Alice verifiably signs each message. We know it is Alice because Alice has a public EOS account and that public key matches each chat signature.

Each EOS account (and therefore Sense Chat account) is unique. No two accounts have the same name. This will prevent many widely exploited vulnerabilities in most social and communication platforms today (such as using the same photo and username).

Sense Chat uses a special “chat” child permission on the EOS account. Sense Chat users will be able to change the keys to this permission at any time outside of the app and re-import them. While that will not change the older messages, future messages will use the new key and this can be verified. If a user is concerned about their key having been compromised, they can change their key outside of Sense, import their account and all future messages will use that new key.

Sense Chat User Authentication

Sense Chat uses keys to authenticate accounts. Each account has a public key stored on the EOS blockchain. Each public key has a corresponding private key completely controlled by each user.

Instead of only generating keys from within the chat app, Sense Chat uses the public and private keys associated with the EOS Blockchain for a given account. This can be generated offline, or by any means, with the account being imported back into Sense Chat.

The encryption of chat messages works with keys imported from an existing EOS account or keys that have been generated locally on the device using EOSJS. Those keys are then further encrypted using device and app passwords. Private keys are never transmitted or stored outside of the device. Most critically, Sense is not able to read any private user messages for harvesting or collecting private chat information. We will soon release information about our 3rd party audits to verify these claims.

Technical Explanation of the Sense Chat Encryption Protocol

The Sense Chat Encryption Protocol uses advanced cryptography combined with the EOS Blockchain to deliver messages so that users will be able to “Trust No One” and maintain the privacy and security of their communication in an unparalleled, provably secure application.

The Sense Chat Encryption Protocol uses both asymmetric key encryption in a unique way. Users do not have to trust Sense Chat with their keys since they have complete control over them. Any user can change their keys at any time using cleos or an EOS interface such as Scatter / EOSToolkit. No other chat application that we are aware of provides this level of control over keys to the user. This is made possible by using the EOS Blockchain. Ephemeral decrypt keys are generated per EOS-peer-keypair when the connection is formed between peers.

The Sense Chat Encryption Protocol does not transmit or receive keys from a central server. All account keys are stored on and referenced from the EOS Blockchain. Since the EOS account keys are retrieved via the EOS API, we do not have to trust the key being sent to us. The latest key being stored on-chain is used to encrypt/decrypt messages. As we are sensitive to key overuse, which is why we are implementing high-entropy keys, else messages of the same contents would generate the same signatures and if intercepted, could lead to shared secret discovery.

Sense Chat uses anonymous key agreement via diffie-hellman key exchange. Diffie-Hellman is a widely used method to generate a shared secret based in 2 different location without exchanging information between those 2 locations. Specifically, at Sense Chat we use ECDHE-256 to create a shared secret based on the two peers’ EOS account keys plus an entropic value. The shared secret is created on both peers’ devices simultaneously. Therefore, it does not need to be transmitted between devices or stored on any servers — this secret only lives on the devices and is used to secure the session.

How does 1:1 Chat work with the Sense Encryption Protocol?

End-to-End Encrypted Messaging

Messages are encrypted at the application level using EOS keys as described above. Additionally, they are encrypted in transit by TLS encryption. When two users are online at the same time, the app will negotiate a true P2P connection. When network conditions are imperfect, it will use servers temporarily to make the connection. Encrypted chat messages cannot be read by the server or any intermediaries because the decrypt keys are only stored on the devices of the peers. These unreadable encrypted messages are stored temporarily until they are delivered to the peer’s device. Messages stored in the device’s local storage can be permanently deleted by the user from their own device (not the device it was delivered to). We are working on implementing ephemeral messaging where messages will be automatically removed from local storage on both devices after a set time period.

When Alice sends a message to Bob, first she generates a shared secret using Bob’s public key and her own private key. The shared secret is used to encrypt the plaintext message, then the encrypted message is sent to Bob. When Bob gets the encrypted message, his device looks at Alice’s public key and his private key + an entropic value to generate the same shared secret as Alice generated on her device. Then Bob uses the shared secret to decrypt the message.

How do Encrypted Video and Audio calls work in Sense Chat?

End-to-End Encrypted and Ephemeral Calling

Sense Chat Video and Audio calls are established over webrtc secured by TLS. In ideal network conditions, this will not require any servers once a connection is made. Sense Chat uses servers for signaling of these data connections. If network conditions are not ideal, then encrypted data may travel through a TURN server, but it cannot be read by 3rd parties due to being encrypted.

Channels

Channels will have 2 types: Public and Private. Private Channels will be permissioned, so users must request or pay to join. These will be useful for people who want to have a group chat with lots of users around a topic or common interest.

Very soon, users will be able to create their own Channels. Channels will be purchasable using Sense tokens.

Sense Chat Public Channels can be accessed by anyone using Sense Chat. Therefore, Public Channels do not have a reasonable expectation of privacy. All of these chat messages are encrypted using TLS during transit.

Each message is signed by your private key and can be verified by other users by referencing your public key on the blockchain. These messages are stored on a server unencrypted, however, Sense Chat has a feature where the creator of any message can be verified. This verification will prevent any impersonation attacks common on other chat applications. Verification is based on the latest public key available on the EOS API.

We are testing an implementation to store these public channel messages on-chain.

Additionally, Public Channels have features such as pumping (weighting of messages via tokenized-likes), threading, and discoverability via web/search.

Private Group Chat

End-to-End Encrypted

Sense Chat Private Groups are currently in development and testing phases. There are many moving parts to these and we want to make sure they are solid before we start to release them. We are planning to have these in the app by v2.0. Here is how they work:

The private groups use a shared-key exchange. An initial key will be created when a new group has two or more members. The key is salted with additional parameters and the Sense Chat Encryption Protocol is used to share it among future members. Each time the members change, the key also changes. When membership of the group changes, they key will also change and it will be distributed to each member encrypted by their EOS public key from the owner of the group. Messages will be stored on a server (or blockchain), but they cannot be read by anyone who does not have the keys.

Sense History

Consistent with our original whitepaper and goals, we seek to empower users to earn by sharing knowledge through a decentralized, transparent messaging platform with knowledge attribution and rewards for contributions. This vision is still very much alive at Sense Chat Labs today and we have evolved our efforts into developing tools to enable this type of information and value exchange. With Sense Chat we are enabling users to own and control their data and how it is distributed and monetized in a state-of-the art messaging platform with provable security.

More on the Sense Token coming soon in Purple Paper: Part 2.

Conclusion

Communication has come a long way in the past 30 years, as well as the importance of implementing cryptography to protect the security of our communications. Only recently, technology and tools have become readily accessible to people all over the world to make using cryptography easier. Specifically, blockchain enables us to secure our digital lives with our own keys that are not stored centrally. No one can hack a server with your information and make off with identity, data, and passwords of millions of users. Sense Chat has taken lead in solving a major modern day problem with data breaches, on top of making communications more verifiable and secure.