Introduction
Adam Isles and Andreas Kurland from our Cybersecurity team discuss the infiltrations of the Salt Typhoon security breach with the CISO Tradecraft podcast. As the U.S. government reveals that intrusions into telecom companies are deeper, more wide-spread and more severe than previously known, it is essential to incorporate end-to-end encryption into communication methods.
What Happened
The Federal Bureau of Investigation (FBI) and Cybersecurity and Infrastructure Security (CISA) warned in November that Chinese-affiliated actors had targeted U.S. commercial telecommunications infrastructure in a wide-ranging cyber espionage campaign. The past week has seen a flurry of additional concerning disclosures. After briefings by officials from the FBI, CISA, and the Federal Communications Commission (FCC) on December 4th, Senate Intelligence Committee Chair Mark Warner (D-VA), a former telecom executive, was candid in his assessment of the incident:“[it is] far and away the worst telecom hack and the fact is that they are still in the systems.”
Details of the widespread breach have come to light, including indications that the content of text messages, voicemails, and phone calls may have been accessed by the foreign actors. This has prompted a stunning change of message from Washington, albeit not in the form of an official statement, alert or directive.
On December 3rd, an unnamed senior FBI official along with Jeff Greene, Executive Assistant Director for Cybersecurity at CISA urged Americans to use encrypted messaging apps to minimize the chances that unauthorized parties can intercept their communications. This is in stark contrast to past concerns raised by the FBI specifically about communication platforms that offer end-to-end encryption (E2EE). The FBI has historically argued E2EE severely hampers its ability to investigate criminal activity, child exploitation and terrorism cases.
There is still some ambiguity around the FBI’s official stance regarding encryption, as some later reporting clarified that the FBI is calling for “responsibly managed” encryption which allows US law enforcement to access encrypted data with a court order. This is seemingly in conflict with the recommendations to use E2EE as in the latter case service providers do not have access to the encryption keys necessary to decrypt content (only the sender and receiver do) and thus would not be able to comply with a court order to decrypt.
The following day, Anne Neuberger, Deputy National Security Advisor for Cyber and Emerging Technology, revealed in a press briefing that at least eight U.S. telecommunications companies were compromised in the brazen campaign, which started one-to-two years ago.
In response to this evolving threat, CISA, NSA, FBI, and Five Eyes partners published Enhanced Visibility and Hardening Guidance for Communications Infrastructure to “highlight this threat and provide network engineers and defenders of communications infrastructure with best practices to strengthen their visibility and harden their network devices against successful exploitation carried out by PRC-affiliated and other malicious cyber actors.”
An announcement from CISA Director Jen Easterly followed that the independent Cyber Safety Review Board will begin an investigation into the unprecedented hack of global telecommunications systems by Chinese state-sponsored groups including Salt Typhoon. In late November, a former Verizon worker was sentenced to four years imprisonment after admitting his role as an informant for China’s Ministry of State Security since 2012.
Targeting of telecoms companies is not limited to state actors. Last week, the U.S. Department of Justice also unsealed a criminal complaint against an alleged co-conspirator of the cyber extortion group Scattered Spider. The complaint alleges that the defendant successfully infiltrated two telecoms providers (one U.S. and one European) and used them as platforms for onward targeting of victims.
Why it Matters
This incident highlights the scale of vulnerability in our core telecommunications infrastructure and the importance for organizations large and small to review how they communicate given this new risk landscape. This review should include assessing what information is regularly transmitted, the sensitivity of the information, the risk to operations if unauthorized disclosure occurs, and finally the practical ways to protect sensitive information. What these latest incidents have made plain is that it is critical to seek solutions that provide E2EE ensuring even the communication platform service providers are not privy to message content. This requires re-examining communications across text messaging, voice calls, virtual meetings and through email.
What to do about it
Here’s an overview of the current risks, encryption capabilities, and specific considerations when deciding how to use the most common communication methods. This information expands upon the risks and recommendations identified in Chertoff Group Director Adriana Petrillo’s October blog post which highlighted Chinese-sponsored groups including Salt Typhoon targeting U.S. telecommunication firms and internet service providers.
Specific to Mobile Device and Computer Messaging
SMS and MMS do not encrypt the information being sent so the risk of information disclosure is present. These forms of messaging should only be used for non-sensitive communications.
Apple’s iMessage and Android’s RCS (developed by GSM Association) do provide E2EE when the sender and receiver are on the same platform (Apple to Apple, Android to Android). There is risk that mobile devices may downgrade to using SMS or MMS if the recipient’s device does not support the protocol, the protocol is not configured, or there is no internet connection.
Currently, neither iMessage nor RCS supports E2EE between Apple and Android devices. By default, cross platform communication is via plaintext SMS or MMS.
Computer-based messaging apps including Microsoft Teams Chat, Slack, Discord, Skype, and Cisco Jabber do not provide E2EE. There are computer desktop apps available for Signal and WhatsApp which do provide E2EE.
Chertoff Group Recommendation: Use Signal, WhatsApp, or Wire for mobile device messaging, or the desktop versions if on a computer, when sending sensitive data as these provide true E2EE including cross-platform, provided the official apps are used.
Specific to Voice Calls
Cellular voice calls may be susceptible to interception and eavesdropping, including in cases where Nation State threat actors have compromised mobile carrier infrastructure. The risk here may be low, however there are many free and paid apps that provide independently validated E2EE for voice calls. Use these to ensure privacy.
Landline voice calls are very susceptible to wiretapping and eavesdropping and thus should be avoided for discussing any sensitive information.
Chertoff Group Recommendation: Use Signal, WhatsApp, Wire, or FaceTime for sensitive voice calls as these provide true E2EE including cross-platform, provided the official apps are used.
The following table provides a comparison of Signal, WhatsApp, Wire, and FaceTime based on encryption protocols, transparency, security reviews, strengths, and limitations. Use this as well as additional details each platform provides to decide what solution may be best for each requirement and use case:
| Messaging Platform | Encryption Protocol | Protocol Transparency | Audit Frequency | Strengths | Limitations |
| Signal | Signal Protocol (derived from the Double Ratchet Algorithm) | Open-source | Regularly reviewed | Best-in-class encryption; no metadata collection. | Dependency on centralized servers for key exchange. |
| Based on Signal Protocol (derived from the Double Ratchet Algorithm) | Uses Signal Protocol but actual implementation is Closed-source | Reviewed periodically | Strong encryption implementation; wide adoption. | Metadata collection (who you communicate with, when, and for how long); unencrypted cloud backups. | |
| Wire | Proteus Protocol (based on Signal Protocol with modifications) | Open-source | Independent audits | Multi-device synchronization; GDPR focus. | Metadata handling concerns for enterprise versions. |
| FaceTime | Proprietary (using AES-256 and Curve25519 for encryption) | Closed-source | Limited independent reviews | Strong E2EE within Apple’s ecosystem. | Closed-source encryption limits external validation. |
Specific to Virtual Meetings
Virtual meeting platforms offer varying levels of encryption with some requiring specific configurations within the client’s dashboard.
| Meeting Platform | Encryption in Transit | E2EE Available | Notes |
| Zoom | AES-256 | Yes for 1:1 calls; yes, for group meetings up to 200 people when enabled by the meeting host | E2EE must be enabled in account settings and requires all attendees join from the Zoom desktop app or mobile apps; Some features including cloud recording, live transcription, and polling are not available with E2EE meetings. |
| Webex | AES-256 | Yes for 1:1 calls; yes for group meetings up to 1,000 participants when enabled by the meeting host and specific conditions are met. | E2EE must be enabled in account settings and requires all attendees to join from official Webex apps. By default Webex cloud-based Key Management System (KMS) generates and distributes keys so Webex cloud can access and use these keys but only to decrypt data as required for core services. Webex offers an enhanced zero trust option, where keys are generated and remain on user devices, and on this configuration, the Webex service cloud does not have access to these keys thus ensuring full E2EE. |
| GoToMeeting | AES-128 | No | Data encrypted in transit, but not E2EE. |
| Google Meet | AES-128 | No | Data encrypted in transit, but not E2EEd. |
| Microsoft Teams | AES-256 | Yes for 1:1 calls; No for group meetings | E2EE for 1:1 calls must be enabled, and it comes with limitations (e.g., certain features like recording and live captions are disabled); Data for group calls/meetings is encrypted in transit and at rest, however Microsoft retains the encryption keys and thus has full access to the data. |
Chertoff Group Recommendation: Use Zoom or Webex, both of which provide E2EE regardless of client device, as long as E2EE is properly configured and the official apps are used.
Specific to Email
Email platforms offer varying levels of encryption with some requiring specific configurations within the platform.
| Email Platform | Default E2EE | Options to Use E2EE | Notes |
| Gmail | No | Secure/Multipurpose Internet Mail Extensions (S/MIME) or Virtru for Gmail | Encryption in transit with TLS; No true E2EE. |
| Outlook | No | S/MIME (Microsoft 365) Pretty Good Privacy (PGP), or Virtru for M365/Outlook | Encryption in transit with TLS; No true E2EE. |
| Apple Mail | No | S/MIME or PGP | No default E2EE for email; Encryption in transit with TLS. |
| Proton Mail | Yes | None (default E2EE for all Proton Mail users) | True E2EE, Proton Mail does not have access to your emails. |
| Tutanota | Yes | None (default E2EE for all Tutanota users) | True E2EE, no ads, no tracking, encryption by default. |
| Zoho Mail | No | S/MIME (paid users) | Encryption in transit with TLS; No default E2EE. |
| Yahoo Mail | No | None | Encryption in transit with TLS; No default E2EE. |
| FastMail | No | Open PGP (manual setup) | Encryption in transit with TLS; OpenPGP can provide E2EE. |
Chertoff Group Recommendations: Configure and use S/MIME, PGP, or a commercial solution like Virtru or Proton Mail, to ensure sensitive emails are E2EE. Consider sharing files through secure document repositories that provide E2EE and granular access controls (as detailed below) instead of emailing documents.
Specific to Enterprise File Sharing: Similar to the above, it’s important to understand how different enterprise file sharing platforms treat encryption and access controls. The table below summarizes this.
| File Sharing Platform | End-to-End Encryption (E2EE) | Encryption Protocols Used | Who Holds the Encryption Keys? | Granular Access Controls |
| Google Workspace* | ❌ Not natively supported. Third-party tools like Cryptomator can be used. | AES-256 encryption at rest, TLS encryption in transit. | Google holds the keys. Encryption managed by Google. | ✅ Supports sharing permissions (view, comment, edit) and expiration dates. |
| Microsoft OneDrive* | ⚠️ Partially supported (E2EE for Personal Vault only). Not full-platform E2EE. | AES-256 encryption at rest, TLS/SSL for data in transit. | Microsoft holds the keys. Users cannot manage keys directly. | ✅ Granular controls, password-protected links, and expiration dates. |
| SharePoint* | ❌ Not natively supported. Data is encrypted at rest and in transit. | AES-256 encryption at rest, TLS/SSL for data in transit. | Microsoft holds the keys. Encryption is managed by Microsoft. | ✅ Comprehensive permissions management for files and folders. |
| Dropbox | ❌ Not natively supported. Third-party tools like Boxcryptor can add E2EE. | AES-256 encryption at rest, TLS/SSL for data in transit. | Dropbox holds the keys. Encryption is managed on their servers. | ✅ Granular controls with password-protected links and expiration dates. |
| Box.com | ❌ Not natively supported. Box KeySafe allows user-managed encryption keys but not true E2EE as Box retains ability to access encrypted data. | AES-256 encryption at rest, TLS/SSL for data in transit. | Box holds the keys unless using Box KeySafe for custom management. | ✅ Advanced permissions, custom workflows, and expiration settings. |
| Egnyte | ❌ Not natively supported. Encryption keys managed by Egnyte. | AES-256 encryption at rest, TLS for data in transit. | Egnyte holds the keys unless integrated with customer-managed tools. | ✅ Detailed access permissions and integration with security policies. |
| Tresorit | ✅ Fully supports E2EE for all files and metadata. | AES-256 for file encryption, RSA-4096 for key exchange, HMAC for integrity. | User holds the keys. Tresorit does not have access to encrypted files. | ✅ Strong access controls, including password-protected links and expiration settings. |
| Proton Drive | ✅ Fully supports E2EE for all files and metadata. | AES-256 for data encryption, RSA-4096 for key exchange, OpenPGP-based. | User holds the keys. Proton Drive cannot access the files. | ✅ Granular sharing options with password-protected links. |
*Virtru provides a commercial solution that integrates with a number of file sharing platforms.
Secure By Design Considerations: For all the above-cited capabilities, security teams should also under take continuous due diligence on how well secured relevant products are in both design and deployment. As an example, supply chain cybersecurity risk management guidance specific to the retail sector can be found here.
Staff Awareness and Training Considerations: For all the above recommendations around using E2EE communication methods, it’s crucial that this be well socialized and modeled within the organization. Security awareness and training campaigns should include references and examples of approved and secure communication methods. Likewise, leaders within the organization up to the C-Suite should “walk the walk” by using these methods in everyday communication within and outside the organization.
Listen to Andreas Kurland and Adam Isles discuss this issue on the latest episode of CISO Tradecraft on YouTube. It is also available on Apple and Spotify.
Andreas Kurland is a Senior Associate in the Cybersecurity Practice at The Chertoff Group. Previously, he spent 11 years within the U.S. Department of Defense managing IT operations, performing system, network, and security administration, and supporting defensive cyberspace operations. You can connect with Andreas on LinkedIn
