Encryption, and more specifically, End-to-End Encryption (E2EE), has reached buzzword status in the collaborative communication industry, and there have been many questions about what E2EE does and, perhaps more importantly, doesn’t mean for an enterprise collaboration system. To address these, we should first consider which problems encryption solves. Then we will examine how to construct a global threat reduction strategy for those problems and discuss where E2EE fits into such a framework.
This seems like a simple question, but most people, if pressed, cannot readily answer it. In point of fact, encryption addresses Confidentiality and Integrity, two of the main cornerstones of the governing principles of modern data security (the other being Availability, collectively forming the so-called C-I-A Triad).
Confidentiality refers to the need to ensure that only authorized individuals have access to your data. Encryption protects Confidentiality by encoding the datastream in such a way that it becomes very difficult for an unauthorized system, device, or person to decode it.
Integrity refers to the need to ensure that user data is accurate and has only been modified in an authorized manner. Encryption protects Integrity by making it substantially easier to detect if data has been changed (using techniques such as digital signatures).
There are three main categories or states of data that can exist in or between systems.
Pexip’s self-hosted Infinity software deploys multiple encryption algorithms for DIT and DAR across the Open Systems Interconnection (OSI) stack. We deploy IPsecv3 for Network Layer security between each system Node; TLS v1.2 and DTLS for Transport Layer security to endpoints and browsers; and protocols such HTTPS, SRTP, and SSH for embedded Application Layer symmetric encryption. Similarly, we encrypt DAR (such as user/system credentials stored in a database master) using asymmetric protocols that are reversible as needed for access. These protocols work in concert to provide a multi-faceted “defense-in-depth” (DID) approach to encrypting your data.
Learn more about Pexip's secure video meetings solution →
Communication between Pexip Nodes uses ITU-T X.509v3 certificates and is encrypted using IPsec Encapsulating Security Payload (ESP) in Transport Mode. Pexip uses the US National Institute of Standards and Technology (NIST) Advanced Encryption Standard (AES) in 256-bit Galois/Counter Mode (GCM) and a 4096-bit Diffie-Hellman (DH) modulus. During the initial session negotiation process, Pexip defaults to those cryptographic algorithms based on Enhanced Elliptic Curve Diffie-Hellman (EECDH) or Ephemeral Diffie-Hellman (EDH) using AES (1). We deploy Transport Layer Security (TLS) v1.2 to encrypt signaling and management protocols, including:
Pexip’s media encryption uses AES128 for H.323 sessions as specified in ITU-T H.235. For Session Initiation Protocol (SIP), Microsoft Teams, or Google Hangouts media sessions, Pexip deploys Secure Real Time Protocol (SRTP) using AES-256 GCM as a default, while clients may negotiate down to AES-128 GCM or AES-128 Counter Mode (CTR). SRTP keys are either negotiated in the signaling channel using Session Description Protocol Security Descriptions (SDES-SRTP) or in the media channel using Datagram Transport Layer Security (DTLS-SRTP).
In Secure Mode, the crypto suite presented by Pexip is actually more restrictive than those permitted by the NIST Federal Information Processing Standard (FIPS) 140-2. AES-GCM-256 and 4096-bit DH meet or exceed the standards for symmetric encryption and key exchange established by the UK’s National Cyber Security Centre (NCSC), the US National Security Agency’s Commercial National Security Algorithm Suite, and the Australian Cyber Security Centre, among others (2). This approach positions customers requiring the highest levels of security for maximal protection through the next decade.
Read more about privacy and security at Pexip →
According to NIST, the current minimum encryption standard to counteract quantum cryptography requires 112 bits of security through 2030 and 128 bits thereafter. Per FIPS 140-2 IG 7.5, RSA-4096 approximates 148 bits of security.
It is important to understand that encryption alone is insufficient to meet even minimal data security and personal privacy standards. Organizations and individuals must instead employ a holistic data security architecture encompassing a comprehensive cybersecurity threat model, of which encryption is only a subcomponent. There are multiple user privacy and organizational data protection elements which encryption does not address, such as authentication, privilege escalation, non-repudiation, and system availability, to name but a few. All too often, relying exclusively on E2EE across public networks creates a false sense of security in practitioners and users, as by their very nature, the networks themselves are not controlled by the users or their organizations. If you don’t know how your data is transmitted across these networks, or to whom, then merely encrypting that data cannot guarantee your privacy. Put another way, most encryption solutions impact the media stream; but who controls the management layer or the metadata generated by the data exchange? How does the system assure participants’ identities?
Relying exclusively on inline session encryption for data privacy engenders a false sense of security for both the system owners and its users. Consider the example of two users deploying a consumer E2EE tool to communicate between mobile devices. The application itself requires user registration, and the far-end user is known or identified in some way, even if potentially via an alias or private ID. While the content of their shared session may be fully encrypted, the session metadata can reveal almost as much data as the session itself. From the perspective of user privacy, the following data can be easily detected and analyzed:
You may recall a 2017 incident in which US soldiers (and others) revealed the location of military bases in places like Somalia and Afghanistan simply by using a fitness application. In a similar manner, Call Data Records (CDRs) reveal almost as much intelligence about users and sessions than the actual conversations conducted within those sessions. Software-as-a-Service (SaaS) providers requiring pre-registration before use already have sufficient data to begin constructing a full profile on each user, even before the user participates in a single session on that service. The risk of this occurring is even higher if the application inherits user profiles from an external user IdAM tool or gateway portal, which is common in Single Sign On (SSO) environments.
Consider the example of a telemedicine patient using a common SaaS tool for his mental health therapy session. Regardless of the encryption method, the fact that the patient is speaking to a psychiatrist may be easily discerned depending on the CDRs of that call. This is almost as damaging to an individual’s privacy as a copy of the therapy session itself would be.
To be sure, some of these data exchanges are inevitable, and users will often benefit from such features (such as SSO). Under such circumstances, however, users and organizations should recognize, assess, and monitor the ability of the service provider or vendor to ensure that their collaboration products are providing full data security.
Learn how to take back control of your metadata with Pexip →
Questions that individuals and organizations should be asking external vendors include:
|
Which regulatory frameworks and jurisdictions govern the communication signal chain? Do you have ownership over every network segment and interface? If not, who does, and what restrictions or oversight do these third parties have over your data? |
|
|
Does the service provider or organization have a published data privacy policy or Information Security Management System (ISMS)? Is the ISMS based on, and evaluated against, a recognized industry or global cybersecurity standard, such as ISO 27001? How transparent is the service provider or tool vendor about these practices?
|
In addition to application security, our platform:
It is a relatively simple matter to trust a single endpoint or user in a consumer-level E2EE collaborative application. For example, when a user reaches out to a specific endpoint or account, we can reasonably expect that the near and far end participants are known to each other and can mutually identify each other via normal social interaction -- video evidence, voice cues, shared experience, etc. Consider, however, two alternative use cases. In the first instance, a new patient is using a telemedicine service. Neither the service clinician nor the patient have any real knowledge of the identity of the other and must trust the system to handle mutual authentication. In the second, a financial corporation’s all-hands meeting supports hundreds or even thousands of participants. In this case, it is not feasible for the meeting host (or even a small group of co-hosts and facilitators) to authenticate each user manually, even if their identities are known (which is unlikely). Once again, each participant must trust the system’s onboard registration process. In each case, the level or type of encryption is irrelevant to resolving the inherent challenge of the situation.
Note that the perception of E2EE providing “full security” actually exacerbates this problem, since unauthorized participants may be falsely considered to be part of the trusted core group. From a technical perspective, synchronous communication tools such as SIP include media encryption keys in the signalling exchange. This architecture assumes that each endpoint in the session is already trusted. The follow-on encryption serves to protect non-trusted entities outside the session, such as network packet sniffers or inspection tools, from compromising the confidentiality of the discussion. However, if malicious actors have compromised the session or one of its endpoints, then the encryption method is irrelevant, as the keys for that encryption will be passed to the threat actor as part of the normal call negotiation handshake.
Our all-hands participants and our telemedicine patient may well let down their guard if they believe that their encryption scheme provides all the data protection they need, which, to be fair, is a natural response. Rather than placing the onus on the user to control their personal data in an unfamiliar system which they do not own, collaborative tools must provide a robust IdAM capability to facilitate user trust and simplify system use.
Further, the risk profile of a collaborative session becomes inherently more complex as participant counts increase. Session and organizational hosts should recognize that they are accepting the privacy and data ownership responsibilities for all of their meetings’ participants, not just themselves. Using our financial corporation example above, an uninvited lurker or malicious user could compromise the data of any of the thousands of participants, in addition, of course, to the company’s proprietary work product.
Authentication is the process of verifying identity (3). The most effective way to bypass an encryption mechanism is to impersonate a trusted user or partner, thereby rendering encryption moot. If the sender shares the encryption key with a spoofed user account (or simply ignores encryption altogether), then there is no need to crack the algorithm. To combat this issue, we recommend that users should integrate Pexip Infinity with a preferred enterprise authentication mechanism. This approach simplifies the burden of verifying identities for dozens or hundreds of potential session participants and allows organizations to leverage the multi-factor authentication (MFA) capabilities of their in-house IdAM tools. For public or guest systems, one-time authentication mechanisms provide reasonable identity assurance while maintaining the integrity of the trusted identity environment.
For organizations requiring even more stringent access control, Public Key Encryption (PKE) may be an optimal choice. Pexip customers such as the United States Department of Defense (DoD) and the Department of Veterans Affairs (VA) use PKE to eliminate passwords entirely and restrict system access to externally validated individuals using hardware tokens or smartcards. Each token features a uniquely encrypted public key certificate, which the individual user unlocks using a Personal Identification Number (PIN) or passcode via the local operating system (OS) trust store before application access is ever granted (4). The Pexip management interfaces support full integration with PKE certificate-based session negotiation using the ITU-T X.509v3 standard for system administration and monitoring.
Token-based Public Key Infrastructure (PKI) allows such organizations to own the token-granting and maintenance process entirely if they so choose, providing an additional layer of operational security to the authentication Defense-in-Depth model. For example, organizationally-administered tokens are substantially more difficult to compromise than personal authentication mechanisms such as smartphones. This also allows organizations to support unique Certificate Authorities and Trust Chains embedded within their PKI, meaning that users outside the organization have no ability to access the systems and the data inside without obtaining an organizationally-specific token (the process for which can be governed as extensively as necessary to protect your data).
Interestingly, token-based PKE/PKI reverses the traditional order of Two Factor Authentication (2FA). Normally, under 2FA, the first factor (the user password) is something you know. The second factor, often a temporary code distributed by text or application, is something you have (formally, a physical device such as a mobile phone should serve as this factor) (5). Only after the first authentication factor is processed does the second authentication factor request initiate. With PKI tokens, however, the token (something you have) is first required to initiate the authentication process, while the PIN or passcode (something you know) is only ever requested after the token is presented. The advantage of this approach is that the Knowledge factor technically only ever unlocks the Possession factor and is independent of the targeted application or system. PKI system users do not, therefore, need to know separate passwords for each application.
The third leg of the C-I-A Triad, Availability, refers to the ability of authorized users to access and use data. Availability is often overlooked in the push to secure real-time applications, but its importance cannot be overstated. After all, if data cannot be accessed, it is essentially useless. In our hyperconnected world, this is more than an annoyance -- it is an operational mission challenge with real-world consequences. Hospital patient data is an example of organizational data that causes substantial harm when availability is compromised (such as via ransomware attacks).
Importantly for our discussion today, deploying encryption (of any type) has almost no impact on availability. A malicious actor does not need to know the content of your data to either delete it, encrypt it with an unknown key, or prevent you from accessing it (for example, via a Distributed Denial of Service attack). There are three main Availability principles that a given collaboration session must support:
By dispersing conferencing hosts (Nodes, in Pexip parlance) across multiple geographic and logical zones, organizations create a distributed conferencing mesh environment in which each Node contributes to the overall system availability capability, but no single Node is solely responsible for any session path (unless the organization specifically designates it so). In the Pexip ecosystem, if a given Conference Node is offline, the Pexip Management Node will reroute each session request to the best available option in real-time, without any interaction or direction required by system administrators and with no impact to the user base.
That said, optimizing resources to meet global Availability requirements can prove challenging. Too often, the Availability solution for exasperated CIOs is to overprovision resources in anticipation of maximal events, given the bursty nature of human communications (sometimes referred to as “The 11 AM Problem”)(6). By implementing a Burst Plan, organizations can sustain their Availability metrics in accordance with their internal Service Level Agreements (SLAs), while optimizing costs to a lower operational baseline.
To combat this, Pexip features the ability to burst capacity on the fly, either on an automated or manual basis. The Pexip Smart Scale capability activates at the hypervisor layer, spinning up pre-configured virtual machines to augment capacity pools on a momentary basis. Some organizations take this ability a step further and choose to declare a non-linear capacity baseline, as shown below.
In this example, which reflects a potential distribution for an internationally distributed organization, a Node Activation Plan would result in using 57% fewer resources than provisioning all systems to the anticipated daily maximum. Using existing automation tools and the Pexip Management Node APIs, the designated number of Conference resources will activate or de-activate as each day progresses.
Non-repudiation refers to the ability of a system to provide assurance that a given user performed a given action. In other words, users (or systems acting as users) cannot repudiate the actions they have undertaken. Non-repudiation has particular importance in legal and compliance venues, but also in the realm of transactional communication, such as banking or stakeholder voting. For technical purposes, non-repudiation is critical for diagnostic analysis, as you must be able to clarify “who did what and when” when traffic flow issues arise.
Under certain circumstances, encrypted communications can actually hamper non-repudiation efforts, since the subject of the exchange is unknowable to non-participants. As such, the Pexip Infinity platform features two distinct auditing methods based on metadata and administrative monitoring to assist with non-repudiation while protecting sensitive information. The Management Node serves as the aggregator for both Call Data Records (CDRs) and administrative function auditing in the form of syslogs. Using the Management Node in this capacity allows both application administrators and system administrators to deploy and monitor an independent action verification mechanism, thus allowing organizations to provide transactional assurance to the enterprise. Importantly, although this process uses Node-generated data, the administration and monitoring of such non-repudiation tools relies on third-party systems and lies outside the purview of the Pexip Infinity ecosystem. Our objective, as always, is to give you the power to determine what happens to your data.
All of the security techniques in the world -- including all manner of encryption protocols -- are only as effective as the goodwill of the people and institutions that control them. If your service provider has the ability to manage and monitor your systems and applications, then your organization cannot claim to maintain complete ownership of its data, and your data privacy coverage may be incomplete -- or worse, falsely premised. While Pexip is fully compliant with GDPR and has an extensive platform of data security policies for the Pexip Service, we recognize and respect that many customers require full ownership of their data. For these customers, a self-hosted Pexip Infinity deployment is a preferred option.
For self-hosted customers, whether deploying on-premise, using Pexip Private Cloud, or deploying on a standard Infrastructure-as-a-Service (IaaS) platform, Pexip has positioned our application to insert directly into enterprise architectures focused on data security and privacy. In a self-hosted Infinity environment, you retain complete ownership of all application and operational data. Although this is not a comprehensive list, your organization is the sole arbiter and beneficiary of the following:
The security advantages of this approach cannot be overstated: these are your platforms, your applications, and your policies. Pexip has no control over them, nor would we ever want or need to have it. This approach adheres to the strictest security standards established by such risk management frameworks as GDPR, NIST SP 800-37, ISO 27001, PCI DSS, and HIPAA, among others. We give you direct access to some of the most powerful encryption configuration and management tools in the industry, and we let you govern what you do with it.
Your Data. Your Rules. Our Tools.
That’s The Pexip Way.
Sources: