Skip to main content

End-to-End Encryption

Overview​

MCE already supports a couple encryption-based data protection protocols to guard sensitive information exchanged between users in the chat system:

  1. All network hops between ML components can be protected by TLS 1.2.
  2. Because MCE is built on top of Microsoft technologies, it comes with MS SQL Always Encrypted support straight out of the box. Chat messages can be encrypted at rest so that even those with direct access to the database cannot see them.

MCE End-to-End Encryption (E2EE) goes a step furher and addresses internal security vulnerabilities posed by system administrators who have special permissions to view and change the configuration/data in the system. Specifically:

  • Administrators that have access to encryption keys can decrypt messages.
  • If the column encryption key (CEK) is compromised, all messages can be decrypted for all the chats.
  • Administrators can give themselves access to any chat room in the system and read content directly from the MLA client.

Bad admin threat

E2EE addresses these vulnerabilities by adopting a zero-trust view of the MindLink Anywhere (MLA) Server itself. In this model, messages sent by users in the MLA Client are encrypted before being sent to the ML server. In fact, the client is the only place where messages will ever appear in their plaintext form.

Message encryption keys are created by the participants of encrypted chat rooms in the MLA client using native JavaScript cryptographic APIs. Keys belong to the chat rooms in which they were created and cannot be used elsewhere; this is to limit the scope of damage if keys are compromised. Further to this:

  • Users can create new encryption keys for the chat at any time - all participants will automatically start using new keys when they are received.

  • Policies can be configured to ensure that no one key is used for too long. The key becomes invalid (stale) after a configurable amount of time, and messages cannot be sent with a stale key. One of the participants has to create a new key before message sending capabilities are restored.

  • Users are encouraged to participate in the security protocol of the system by checking the encryption system configuration, which is made available before they create new encryption keys. They can verify that the system aligns with their corporate security restrictions and flag anything that does not look right.

  • Users are able to see the active encryption key at any time, and they also have access to the full record of encryption keys over the lifetime of the group. Each key is verifiably linked to its author and includes other metadata, such as creation time, to provide a transparent record of the encryption key history.

Topology​

The E2EE solution relies on a distributed architecture to round-out the security model. Separately managed systems are configured independently and work together to build up a multi-factor security protocol. A single administrator is unable to manage all of the systems, so control is said to be "compartmentalized".

Because the ML server distributes message encryption keys that users create to the other chat participants, the client must wrap (encrypt) the keys before passing them to the server. It does this by engaging a Community of Interest (CoI) based Public Key Infrastructure (PKI) which is split over two complementary services that handle message key wrapping/unwrapping respectively.

These components must exist in corporate network prior to enabling this feature:

  1. Public Certificate Lookup Service

    This service provides public CoI certificates. The MLA client downloads these certificates and wraps message encryption keys before they are sent to the ML server for distribution.

  2. Decryption Service

    This service has access to the private key component of the CoI certificate. Users present credentials to the service in the form of a client certificate which authorizes them to unwrap encryption keys for the CoIs they belong to.

  3. OCSP Responder (optional)

    Like any PKI, it may be necessary to revoke CoI certificates if they have become compromised or unsafe. For MCE E2EE this is as simple as replacing the certificate in the Public Certificate and Decryption Services. Users will eventually start using the new certificate as they renew their client sessions over time.

    If certificate revocation is more time-sensitive, then clients can be configured to talk to OCSP and get up-to-date certificate status information in real time. If a certificate is revoked it cannot be used to wrap message encryption keys - the client will immediately try to pull new certificates from the lookup service, and failing that, will experience a denial of service until such time as the rest of the PKI infrastructure is brought back into a valid alignment.

E2EE Topology