International Association
for Cryptologic Research

The RADIUS protocol is the de facto standard lightweight protocol for authentication, authorization, and accounting for networked devices. It is used to support remote access for diverse use cases including network routers, industrial control systems, VPNs, enterprise Wi-Fi including the Eduroam network, Linux Pluggable Authentication Modules, and mobile roaming and Wi-Fi offload. This talk presents the Blast-RADIUS vulnerability which allows a man-in-the-middle attacker to authenticate themselves to a device using RADIUS. Even in 2024, many of the above-mentioned applications still run RADIUS over UDP within an enterprise network (and in some cases even over the public Internet), and are hence affected by this vulnerability. RADIUS has previously escaped the scrutiny of the cryptography community, likely because it is predominately used in enterprise contexts and hidden from end users. Only deployments using the EAP authentication method or the not-yet-standardized RADIUS over TLS are unaffected. In a typical RADIUS deployment, a user sends their credentials to the RADIUS client, which then contacts the RADIUS server that validates the credentials. On success, the RADIUS server sends an Access-Accept packet back to the RADIUS client (e.g., a router), which will then grant the user access. The RADIUS protocol predates modern cryptographic guarantees and is typically unencrypted and unauthenticated. However, the protocol does attempt to authenticate server responses using an ad hoc construction based on the MD5 hash function and a fixed shared secret between a RADIUS client and server. Our attack exploits an MD5 chosen-prefix collision to produce Access-Accept and Access-Reject packets with identical Response Authenticators. This allows our attacker to transform a reject into an accept without knowledge of the shared secret. We show how to fit the collision blocks within RADIUS attributes that will be echoed back from the server. We improved and optimized the MD5 chosen-prefix attack to produce collisions online in less than five minutes (which could be reduced with further engineering efforts). This talk discusses proof of concept applications of our attack against popular RADIUS implementations, and the large-scale disclosure process and mitigation efforts in collaboration with CERT and IETF.

Two years ago, at RWC 2023 in Tokyo, we presented attacks on Mega—an end-to-end encrypted (E2EE) cloud storage provider with over 300 million users—and challenges on the path to designing a secure cloud storage protocol with end-to-end guarantees. Now, it is time for an update. In the past two years, analyses of multiple E2EE cloud storage providers revealed serious flaws in most systems, showing that the entire ecosystem is largely broken. At the same time, Google and Apple launched optional client-side encryption for Google Drive and iCloud, thereby making E2EE cloud storage available to their users (albeit with limited functionality). This is great news for privacy-minded users, but given the vulnerabilities that were discovered in most of the smaller providers, one may ask: how do we know if they are secure? Moreover, the vast majority of cloud storage providers still only use server-side encryption, which provides no protection against server compromise. Why is this the case? And what can we do about it? In this talk, we present the first cryptographic model for secure cloud storage in the malicious server threat model, formalizing E2EE cloud storage. Our model and security notions are motivated by our study of real-world E2EE cloud storage providers. We begin by briefly recapping our insights from analyzing MEGA and Nextcloud, identifying the main challenges that they struggled with. We then give a formal syntax for the core functionality of a cloud storage system, focusing on how we tailored the model to capture the real-world complexity of such systems. We continue by showing how we define the expected end-to-end security guarantees against a potentially compromised or malicious cloud server. Finally, we present the first provably secure E2EE cloud storage protocol. Along the way, we hope to inspire a discussion between academia and industry on the remaining challenges of bringing provably secure E2EE cloud storage to practice.

Key derivation functions (KDFs) are integral to many cryptographic protocols, turning raw (e.g., Diffie-Hellman) key material into strong cryptographic keys. Traditionally KDFs are designed and analyzed, for settings where they take a single key material input. Modern protocol designs, however, regularly need to combine multiple secrets (e.g., in hybrid key exchange for quantum-safe migration) with the guarantee that the derived key is secure as long as at least one of the inputs is good. Complex applications, especially in the setting where keys are user-managed, may even require threshold versions of KDFs. In this talk, we present lessons learned from analyzing such real-world proposals for multi-input KDFs. We first discuss combiner KDFs (aka key combiners), studying the designs in Signal's X3DH protocol, ETSI's TS 103-744 standard for hybrid key exchange, and MLS' combiner for pre-shared keys. Notably, the ETSI standard, widely recognized and recommended for use, for example by the German Federal Agency for IT Security, misuses the underlying HKDF salt input in a way that makes it insecure in its general form. We take the opportunity to revisit the syntax and security model for KDFs (mainly due to Krawczyk's HKDF paper, CRYPTO 2010) to give results on multiple-input KDFs. Taking an assertive stand on syntax, we do away with salts, which are needed in theory to extract from arbitrary sources in the standard model, but in practice, are almost never used (or even available) and sometimes even misused, as we saw. We then turn to the novel threshold primitive, which emerged as part of the multi-factor KDF (MFKDF) design (Nair and Song, USENIX 2023). We show how a naive implementation (such as the one proposed in MFKDF) leaves the scheme open to devastating cryptographic attacks and discuss ways forward.

End-to-end encryption (E2EE) allows data to be outsourced and stored on an untrusted server, such as in the cloud, without compromising its privacy. The need for stronger cryptographic guarantees for outsourced persistent data (such as encrypted files in cloud storage) has been highlighted by recent attacks on E2EE cloud storage providers, which all identify sharing as one of the main challenges. But even recently proposed E2EE cloud storage protocols which address this challenge suffer from another problem: when data is shared between a group of users, they all share access to the same, static, key material used for data encryption. This means that when the group membership changes, access control is only enforced by the server; security breaches or compelled disclosure would let even a removed member decrypt both current and future shared data. In this talk, we explore stronger security guarantees for groups of users and the data they share, and implement a practical system that delivers them. We propose to move away from the use of static keys for data encryption in the setting of file sharing. Taking inspiration from the related setting of continuous group key agreement (CGKA) [3] and the MLS standardization effort for group messaging, we introduce a new primitive, called group key progression, that enables a dynamic group of users to agree on a persistent sequence of keys. With our efficient instantiation of this primitive, called Grappa, group members can secure future and past data from former and future group members, respectively, while themselves retaining access to all of their data. We avoid expensive data re-encryption and ensure that all users in Grappa only need to keep a compact cryptographic state. Grappa uses CGKA as a core building block to transport key updates between users, hence finding a use-case for MLS beyond group messaging. In this talk, we want to share our take-aways from the journey of developing a file sharing system with strong security, from the novel theoretical building blocks, to challenges on the path to practice. On the theoretical side, we begin by showing that forward security (FS) and post-compromise security (PCS)—which are standard security notions for data in transit—are fundamentally more challenging to achieve for data at rest. Persistent data hence necessitates tailored methods to ensure strong end-to-end security. Instead of aiming for FS and PCS, we propose the new security notion of cryptographically-enforced interval access control (IAC), which gives similar guarantees in the common setting of persistent data applications where a group of users share access to the outsourced data, such as file sharing. On the practical side, we spent significant engineering effort to implement a file sharing system which utilizes Grappa to achieve both end-to-end security and IAC. In doing so, we uncovered several interesting limitations of the current cryptography ecosystem that we believe to be of interest to the RWC audience. These include the lack of support for low-level cryptographic primitives in the Web Crypto API, barriers to using MLS outside of the secure messaging context as a transport layer for Grappa, and challenges with developing new cryptographic applications for cross-platform usage.

Users increasingly store their data in the cloud, thereby benefiting from easy access, sharing, and redundancy. To additionally guarantee security of the outsourced data even against a server compromise, some service providers have started to offer end-to-end encrypted (E2EE) cloud storage. With this cryptographic protection, only legitimate owners can read or modify the data. However, recent attacks on the largest E2EE providers have highlighted the lack of solid foundations for this emerging type of service. In this paper, we address this shortcoming by initiating the formal study of E2EE cloud storage. We give a formal syntax to capture the core functionality of a cloud storage system, capturing the real-world complexity of such a system’s constituent interactive protocols. We then define game-based security notions for confidentiality and integrity of a cloud storage system against a fully malicious server. We treat both selective and fully adaptive client compromises. Our notions are informed by recent attacks on E2EE cloud storage providers. In particular we show that our syntax is rich enough to capture the core functionality of MEGA and that recent attacks on it arise as violations of our security notions. Finally, we present an E2EE cloud storage system that provides all core functionalities and that is both efficient and provably secure with respect to our selective security notions. Along the way, we discuss challenges on the path towards bringing the security of cloud storage up to par with other end-to-end primitives, such as secure messaging and TLS.

MEGA is a large-scale cloud storage and communication platform that aims to provide end-to-end encryption for stored data. A recent analysis by Backendal, Haller and Paterson (IEEE S\&P 2023) invalidated these security claims by presenting practical attacks against MEGA that could be mounted by the MEGA service provider. In response, the MEGA developers added lightweight sanity checks on the user RSA private keys used in MEGA, sufficient to prevent the previous attacks. We analyse these new sanity checks and show how they themselves can be exploited to mount novel attacks on MEGA that recover a target user's RSA private key with only slightly higher attack complexity than the original attacks. We identify the presence of an ECB encryption oracle under a target user's master key in the MEGA system; this oracle provides our adversary with the ability to partially overwrite a target user's RSA private key with chosen data, a powerful capability that we use in our attacks. We then present two distinct types of attack, each type exploiting different error conditions arising in the sanity checks and in subsequent cryptographic processing during MEGA's user authentication procedure. The first type appears to be novel and exploits the manner in which the MEGA code handles modular inversion when recomputing $u=q^{-1} \bmod p$. The second can be viewed as a small subgroup attack (van Oorschot and Wiener, EUROCRYPT 1996, Lim and Lee, CRYPTO 1998). We prototype the attacks and show that they work in practice. As a side contribution, we show how to improve the RSA key recovery attack of Backendal-Haller-Paterson against the unpatched version of MEGA to require only 2 logins instead of the original 512. We conclude by discussing wider lessons about secure implementation of cryptography that our work surfaces.

As privacy-awareness rises, demand for end-to-end encrypted (E2EE) services is increasing. However, not all systems live up to their advertised security guarantees. MEGA—the largest provider of E2EE cloud storage with over 260 million users—failed to protect the confidentiality and integrity of their customers’ data, as our recent paper “MEGA: Malleable Encryption Goes Awry” showed. In this talk, we take a step back and discuss why it is surprisingly challenging to design a privacy-preserving cloud storage protocol that is secure even when the cloud provider is actively malicious. Recent academic effort focused on building file sharing systems which hide metadata. However, systems in practice still face much more fundamental challenges including key management, asynchronously coalescing updates stemming from collaboration on shared E2EE files, and cryptographic agility. We briefly discuss the approach of MEGA and how it was susceptible to a key recovery attack that allowed a malicious cloud provider to decrypt user files, among other vulnerabilities. Based on the attacks on MEGA, we suggest best practices for designing secure E2EE cloud storage systems. Unfortunately, it is infeasible for MEGA to completely redesign their system due to scale and backward compatibility. Even if a redesign was possible, the security they currently aim to provide still falls short of offering desirable properties like post-compromise security, forward security, and key rotation. With this in mind, we point out open questions for future work and advocate for a standardization process for a cloud storage design.