End to End Encryption (E2EE) in Microsoft Teams—What Does It Mean To You?

The technology behind encryption has a surprisingly long lifespan—it looks like the first known examples of encryption date all the way back to about 1900 BC, during the reign of Khnumhotep II of Egypt. Since then, it’s fair to say that the technology, use cases, and societal impact of encryption technology have gone well beyond what might have been predicted even recently as 50 years ago.

Before we can dig into what Microsoft’s announcement at Ignite means to you as a user and admin about Teams support for end-to-end encryption, we have some background to cover—I’ll try to keep it short and as interesting as possible for such a complex and sensitive topic.

What we talk about when we talk about encryption

Encryption is just scrambling data using a key, in a way that someone with the correct key can unscramble it. Microsoft supports a number of different encryption algorithms throughout different workloads in Microsoft 365; in general, users and administrators don’t get to pick an algorithm or key strength, as we might have with on-prem products. This is important to remember because what Microsoft is trying to do is maximize protection for customers and Microsoft data and resources throughout the worldwide system while still balancing all their other needs for reliability, performance, and so on. 

You’ll see three applications of encryption commonly discussed. First is encryption at rest, which does what it sounds like: it encrypts stored data so that no one can read it without the key. BitLocker (used on data volumes in many of the Microsoft 365 workloads) is a good example of an encryption-at-rest system. The second is transport encryption (also called “encryption in transit”.) Unsurprisingly, this refers to protecting data transported over a network, usually using TLS.

End-to-end but not beyond

The third application—end-to-end encryption (E2EE)—is the most interesting and the most complicated. You’re probably already familiar with E2EE; examples include S/MIME for email, IPv6 for network connectivity, or Apple’s iMessage service. In an E2EE system, an outgoing message is encrypted on the sending device using a key that only the sender and recipient can access. The encrypted data is moved around as an opaque blob of data that the transport mechanism can’t inspect; there may be message routing data, or other metadata,  that is either left unencrypted or encrypted using a key that the transport mechanism can use to read it. Only the intended recipient can read the message.

Alice, Bob, Eve, and their entourage

You could argue that the modern era of cryptography started when Rivest, Shamir, and Adelman published the eponymous RSA public-key algorithm. Whether or not you agree with that argument, there can be no doubt that R, S, and A had a huge influence on cryptographers because they gave us Alice, Bob, and their friends—Eve the eavesdropper, Trudy the intruder, and so on. E2EE systems are specifically designed to let Alice and Bob communicate “securely,” which in this case means two things:

• Eve can’t eavesdrop; that is, Eve may be able to copy the messages, but she shouldn’t decrypt them. (Even if she can keep copies if the service designers did their jobs right, it won’t be feasible for Eve to decrypt them later.)
• Mallory, the malicious attacker, can’t change the messages in transit.
• If Trudy gains access to the network at any point between the sender and recipient, she’s blocked in the same way Eve is. (Note that E2EE does nothing to protect Alice or Bob against attacks where Trudy attacks their devices; if Trudy can compromise Alice’s device, it’s game over.)

Read more: A Primer for How to Secure Microsoft Teams

E2EE and Teams

Phew. So far, you might be wondering when the hell I’ll get around to talking about Teams, the ostensible subject of this article. With those preliminaries out of the way, now we can get to the good stuff.

Let’s start with a useful fact: all communications between Teams users and the service are already encrypted using TLS. E2EE brings nothing new: when Alice, Bob, Carol, and Dave join a Teams meeting or chat, each connection from a Teams client application and the service is encrypted. And communications within Microsoft’s network between different parts of the Teams and M365 backend are also encrypted. However, Microsoft, or a sufficiently sophisticated attacker, can decrypt and monitor the conversation or meeting content by decrypting it.

E2EE protects against this scenario by encrypting the content on each device. As previously noted, when E2EE’s available, the service just gets an encrypted blob that it can’t read, so that when Alice calls Bob to talk about the super-secret project they’re working on, neither Microsoft nor Eve can read the traffic. But there’s a twist.

In Live Communications Server and its successors, there’s a noticeable difference between 1:1 calls and multiparty calls—the 1:1 calls are routed directly between the two endpoints and don’t pass through the server. That same approach is used in Teams: when Alice calls Bob with Teams, the audio and video streams between their devices are exclusively peer-to-peer unless Alice, Bob, or the service enables a feature that requires the service to be part of the conversation. For example, when you record a call, the Teams back-end services have to “see” the audio/video data to make the recording. That’s where E2EE has historically been unfeasible: you can’t have call recording, live transcription, breakout rooms, or other useful and desirable features unless the Teams service itself joins the meeting as a participant. As soon as you move from 1:1 calls to multi-attendee meetings, key management and distribution become a huge problem. Imagine a 40-person meeting organized by Alice where Bob is the first speaker. Alice and Bob have to have each other’s keys, but every other meeting participant has to have a key to decrypt Alice’s stream and a separate key for Bob’s stream and one for Carol, and so on. The alternative is to have each participant share a key with the service only and let the service take care of multiplexing, encrypting, and redistributing the stream, which is exactly what already happens with Teams’ transport encryption.

When Microsoft ships E2EE for Teams, at a date which they have not specified yet beyond sometime in the first half of 2021, it will first be usable only for commercial customers, only with 1:1 audio or video calls, only when the administrator enables the feature at the tenant level, only for the users who have been granted access to the feature via policy, and only when both participants have opted in. This is a sensible way for Microsoft to proceed because many of their key customers have compliance and security requirements that would be obliterated by the indiscriminate use of E2EE for internal calls. For example, you might imagine that government agencies using the government-specific GCC High or DoD tenants might not want their end-users choosing to encrypt their own calls.

Microsoft’s blog post announcing E2EE was fairly bland, too: “As we release E2EE for Teams 1:1 calls, we will continue to learn from customers how the scenarios address their needs. We will then work to bring E2EE capabilities to online meetings later.” When they do, those capabilities will be somewhat limited. For example, consider the common scenario where you have a meeting attendee who needs to dial into your meeting: if you have E2EE for all meeting participants, there won’t be any dial-in access. The same problem exists with breakout rooms, at least as they’re currently implemented. There are also some unanswered questions about device support—Microsoft hasn’t publicly committed yet to delivering E2EE for any of the current crop of Teams room systems, Teams collaboration bars, and so on.

The future of E2EE

It’s no secret that Microsoft has been working very, very hard to compete with Zoom. At least when it comes to E2EE, “beat Zoom” is undoubtedly an attainable bar based on the list of features that Zoom says are disabled when you enable E2EE in their service. This list gives us a pretty good roadmap for what likely will and will not work in the future for Teams, simply because it is fiendishly difficult to provide securely encrypted versions of many of the most interesting features.  Nonetheless, even basic E2EE support will help organizations, and end-users, protect their sensitive conversations against eavesdropping, and that’s a worthwhile and welcome improvement.

Learn how you can secure Microsoft Teams today in this blog post: A Primer for How to Secure Microsoft Teams