Why study smart locks?

Smart locks are increasingly popular due to their convenience and support of additional features compared to traditional locks. By design, these locks are a critical component for access control, such as when they are integrated into the doors of a private home, Airbnb rental, or hotel. Consequently, any attacks on smart locks has a real-world impact on the physical safety of humans.

What attacks did we find?

In addition to their security-critical use, smart locks also have an interesting deployment model. The D1000 lock is not connected to WiFi itself to save energy and support offline unlocking. Instead, the lock only communicates with the Master Lock servers over the phone of the person unlocking the lock. This is noteworthy because it implies that the lock cannot synchronize revocation events without relying on the phone, but that phone might belong to an adversary!

Therefore, a complex protocol is needed to support all smart lock use cases, giving many opportunities for attacks. Below, we briefly describe the five attacks that we found on the Master Lock Bluetooth Deadbolt D1000 (firmware version 1679338484).

• Attack 1 (session replay): An adversary in physical proximity of the lock (without ever having a valid account on the lock) can record the Bluetooth Low Energy (BLE) communication of a whole session and replay it to repeat all executed commands, including unlocking the lock.
• Attack 2 (exceeding access): Former guests can continue unlocking the lock after their access has been revoked.
• Attack 3 (clock tampering): Malicious guests can adjust the clock time of the smart lock arbitrarily, extending their own access past expiration or locking out all legitimate users.
• Attack 4 (audit log tampering): An adversary that only knows the lock’s identifier (which is advertised over BLE) can upload arbitrary audit events to the telemetry server, and prevent legitimate audit events from being uploaded. Hence, the adversary can hide their own activities.
• Attack 5 (malformed messages): Without valid access, an adversary can send malformed BLE messages to the lock that make it unresponsive or corrupt memory, which results in a Denial of Service (DoS) for authorized users. A malicious authorized user can even leak the memory of the smart lock.

Next, I describe how we pulled off the first two attacks in a bit more detail. The interested reader is encouraged to look at our paper for a more technical description of all attacks and our reverse engineering techniques to overcome Master Lock’s custom obfuscation.

Deep dive 1: authentication and exceeding access

Authenticating to the D1000 smart lock works as follows (illustrated below):

1. The user adds their credentials to the Master Lock app, which uses them to authenticate to the Master Lock server.
2. Server sends a pair of the session key k and the opaque profile to the app. The profile contains the same session key and other information, encrypted with a symmetric key that is shared between the lock and the server.
3. The app then transmits the profile to the lock to start an encrypted session over which it can send commands, e.g., to open the lock.

To revoke the access of a user (e.g., a temporary guest in an Airbnb), the lock administrator can remove that user from an access list that the server keeps. The figure below illustrates that on every login, the app first checks which locks are accessible to the user. Locks that are not available are not shown to the user, even if they are discovered in BLE scans. Moreover, the server also refuses to generate session keys and profiles for locks that the user does not have access to.

How did we bypass this revocation?

Let’s look at this profile that users need for authentication in more detail:

{
    "profiles": [
        {
            "id": 128602,
            "accessProfile": "xnd+jiDJpP587jpvhoHT4yS0GU3fnYlGYM5LzIrFQH8=|gLaPSy/n ...
            "startsOn": "1970-01-01T00:00:00+00:00",
            "expiresOn": "2025-08-02T02:15:17.1199254+00:00",
            "refreshThresholdMinutes": 387360
        }
    ]
}

We notice that there is a hardcoded expiration date in the field expiresOn. This field is also encoded in the accessProfile that the app sends to the lock. For the lock, the expiresOn field is the only way to validate a profile.

However, this means that an attacker can save a session key and the corresponding profile, and use them with a custom BLE client to bypass the restrictions imposed by the official app. Thus, this attack allows users to open the lock up to nine months after their access was revoked.

Deep dive 2: session encryption and replay

After the app and lock exchange a session key over the previously described profile, they start communicating over a secure channel. For this, they use AES-CCM encryption with an implicitly incremented nonce. The figure below shows an example. First, the lock picks a starting nonce n and encrypts the first message m1, producing ciphertext c1. It sends both values to the app. The app then responds by encrypting message m2 (e.g., an “unlock” command) using the incremented nonce n+1. Here, it no longer sends the nonce because the lock can just increment n.

This prevents an adversary from replaying single messages inside a session. For instance, resending c2 means the lock would now attempt to decrypt it with nonce n+3, which fails.

However, we noticed that the D1000 always sends the same initial nonce n. Therefore, the same messages sent in the same order produce the same ciphertexts. This allows an adversary to replay all ciphertexts in the session until the desired command.

Disclosure and mitigation

We thank the Fortune Brands Connected Products security team for a great disclosure experience. We had an in-depth meeting with their team in which they acknowledged our findings in detail, provided context on the origin of these issues, insights into their design decisions, and updates on the mitigation progress.

For the exceeding access attack discussed in more detail above, Master Lock shared that only the D1000 product had a profile validity period of nine months. This was because they had a firmware bug that previously caused the real-time clock of the D1000 lock to jump forward in time. To avoid locking users out, they increased the validity period.

This firmware bug is already fixed in the D1000 firmware that we targeted. Master Lock plans to push out firmware updates to D1000 locks more aggressively and then reduce the validity period of access profiles to seven days, as in their other products.

For the session replay attack, the lock should choose a fresh random nonce from a cryptographically large space for every session. Master Lock informed us that among their products, only the D1000 firmware resets the nonce when starting connections. They will fix this in a firmware update.

All mitigations are described further in our paper.

Acknowledgements

Nadia and I proposed this topic for the Early Research Scholar Program (ERSP) at UC San Diego. The ERSP introduces second-year undergraduates to research, teaching them everything from reading papers to conducting research. As part of this program, Danielle Dang, Sierra Lira, and Angela Tsai found related work, identified a promising target (the D1000), and started setting up the Bluetooth sniffer and prodding the communication protocol.

Towards the end of the ERSP project, when it was clear that we needed a non-blackbox understanding of the protocol, Chengsong—then a master student—joined and reverse-engineered the Android application, which then allowed us to find the attacks.

I myself am grateful for being supported by a Google PhD fellowship, which gives me the freedom to pursue projects like this one that help undergrads and master’s students get into research.

Further Resources

Our paper is available here.

Overview

This is joint work with Matilda Backendal (ETH Zurich), Hannah Davis (Seagate), Felix Günther (IBM Research — Zurich), and Kenny Paterson (ETH Zurich). This post only contains some of the highlights, please read the full version of our paper on eprint.

Users increasingly store their data in the cloud for easy access, sharing, and redundancy. E2EE should protect the data even against server compromise. However, recent research from myself and others has discovered attacks against widely deployed systems. For example, we showed MEGA (300 million users) can decrypt user files (here and their patches for our attacks were broken). Others in Kenny’s Applied Crypto Group showed that Nextcloud could exploit the sharing feature to learn user files.

In other words, we realized that the security of E2EE cloud storage is behind the one of other E2EE applications like secure messaging. There is no rigorous foundation, no security notions, and no provably secure protocols. Instead, deployed E2EE cloud storage protocols are custom designs that attempt to solve many complex cryptographic challenges including password-based key management and file sharing, Despite this complexity, there’s no formal guarantees to back up their security claims.

In this paper, we initiate the formal study of E2EE cloud storage and make four main contributions toward understanding the security of E2EE cloud storage and bringing it up to par with other E2EE applications:

1. We give a formal syntax capturing the core functionality of E2EE cloud storage while honoring the real-world complexity of such systems and supporting interactive protocols and out-of-band channels.
2. We define game-based security notions for confidentiality and integrity of E2EE cloud storage against a fully malicious server, treating both selective and fully adaptive client compromises.
3. We put our model to the test and use it to formally capture some of the recent attacks on MEGA, showing our framework is rich enough to model deployed systems and capture practical attacks.
4. We present an E2EE cloud storage system that supports all core functionality, is efficient and is provably secure with respect to our selective security notions.

We discuss many challenges on the path towards bringing the security of cloud storage up to par with other end-to-end primitives, which are interesting for future research. To only mention a few, one is analysing whether our protocol achieves adaptive security, or if this can be achieved efficiently by another protocol that is based on standard cryptographic assumptions. Another interesting question is to achieve advanced security properties that other E2EE primitives offer, such as forward secrecy and post-compromise security, in the cloud storage setting.

We hope that users will eventually enjoy the benefits of a single, well-analyzed scheme with provable security guarantees, akin to E2EE communication today. Standardization of such a scheme would resolve the long-standing issues that untrusted cloud providers need to be trusted with the design of a secure system and serving benign client code. A standardized scheme could have independent client implementations (i.e., not under the control of the potentially malicious provider) and even lead to interoperability between cloud storage providers. Our work is a first step towards bringing modern cryptographic guarantees to cloud storage.

You can find interesting open problems, our provably secure E2EE cloud storage protocol, game-based security notions that are surprisingly compact for being even more complex than key exchange notions, and pages of beautiful proofs in our paper: https://eprint.iacr.org/2024/989.

Abstract

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.

Acknowledgements

This paper took us more than 2.5 years to finalize. It was probably the most challenging project I worked on so far. The sheer complexity of the models and the infinite design space made it very hard to carve out a well-defined, solvable problem and arrive at satisfying definitions. This would never have been possible without the amazing support that I received.

First of all, I would like to thank my co-authors for all their amazing work, their input and feedback on dozens of iterations of the security game. My thanks goes to: Matilda, for driving the project together with me and doing amazing work on the diligent proof of our protocol; Felix, for helping us with his experience from Key Exchange protocols to cope with the complexity and teaching me how to be concise; Kenny, for guiding us with his decades of experience and unbeatable intuition. Hannah, for writing an amazing section to justify our choice of game-based proofs over UC.

Moreover, I would like to thank Mihir Bellare for his guidance in the early stages of this project and his feedback on my first drafts of the game. I would also like to thank my advisor, Nadia Heninger, for never objecting that I spent considerable time on this project that started before my Ph.D. with her at UCSD, and for her help to write and apply for a grant to fund my work.

Finally, my deepest gratitude goes to Alisha, who supported me in every way possible, from giving feedback on my writing to ensuring I stay sane and healthy around deadlines.

My research was supported by an Amazon Research Award Fall 2023. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not reflect the views of Amazon.

Workshop description

Cryptography is often thought of as the bright spot of practical security, a mathematical paradise where security can be rigorously proven and issues like buffer overflows are in someone else’s department. However, there is a growing community of researchers who regularly find serious flaws in widely deployed cryptographic implementations and protocols. In recent years, this type of research has mostly been published in systems security conferences. This workshop will bring together researchers who work on cryptographic attacks and provide a showcase of their work for the Crypto community. This is the seventh edition of the WAC workshop, which was established by Nadia Heninger.

Workshop website

More information about (current and future) versions of the workshop are on the WAC website.

Abstract

Nair and Song (USENIX 2023) introduce the concept of a Multi-Factor Key Derivation Function (MFKDF), along with constructions and a security analysis. MFKDF integrates dynamic authentication factors, such as HOTP and hardware tokens, into password-based key derivation. The aim is to improve the security of password-derived keys, which can then be used for encryption or as an alternative to multi-factor authentication. The authors claim an exponential security improvement compared to traditional password-based key derivation functions (PBKDF).

We show that the MFKDF constructions proposed by Nair and Song fall short of the stated security goals. Underspecified cryptographic primitives and the lack of integrity of the MFKDF state lead to several attacks, ranging from full key recovery when an HOTP factor is compromised, to bypassing factors entirely or severely reducing their entropy. We reflect on the different threat models of key-derivation and authentication, and conclude that MFKDF is always weaker than plain PBKDF and multi-factor authentication in each setting.

This paper is published at USENIX 2024.

The full version of the paper is on eprint.

Overview

The RADIUS protocol is the de facto standard lightweight protocol for authentication, authorization, and accounting (AAA) 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.

We have discovered a protocol vulnerability in RADIUS that has been present for decades. Our attack allows a man-in-the-middle attacker to authenticate itself to a device using RADIUS for user authentication, or to assign itself arbitrary network privileges. Our attack exploits an MD5 chosen-prefix collision on the ad hoc RADIUS packet authentication construction to produce Access-Accept and Access-Reject packets with identical Response Authenticators, allowing our attacker to transform a reject into an accept without knowledge of the shared secret between RADIUS client and server.

We optimize the MD5 chosen-prefix attack to produce collisions online in less than five minutes, and show how to fit the collision blocks within RADIUS attributes that will be echoed back from the server. We demonstrate our attack in a variety of settings against popular RADIUS implementations. Nearly all RADIUS/UDP implementations are vulnerable to our protocol attack when using non-EAP authentication methods. RADIUS Accounting and EAP authentication appear less practically exploitable, although a theoretical protocol vulnerability may exist. Our attack also requires man-in-the-middle network access. Not all RADIUS deployments are practically exploitable; organizations should independently verify. It is our hope that this attack will provide the impetus for vendors and the IETF to deprecate RADIUS over UDP, and to require RADIUS to run over secure channels with modern cryptographic privacy and integrity guarantees.

This paper is published at USENIX 2024.

Further Resources

More information on the paper, how the attack works, mitigations, and frequenlty asked questions is available on our website blastradius.fail.

Our paper is available here.

Workshop description

The Cryptographic Applications Workshop (CAW; the constructive twin of WAC) focuses on the construction and analysis of cryptography built for practice. Inspired by the Real World Crypto Symposium, it aims to provide a forum for cryptographers in academia and industry to exchange ideas and insights, bridging the gap between research and real-world applications. The main themes of CAW are

1. formalizing the security of deployed cryptography,
2. constructing cryptographic primitives and systems for practice, and
3. the industry perspective on deployment and maintenance of cryptography.

The workshop consisted of a mixture of invited and contributed talks on recent contributions and developments in the field of applied cryptography.

Workshop website

More information about (current and future) versions of the workshop are on the CAW website.

Abstract

End-to-end encryption is rapidly becoming the accepted security goal for personal data. In this article, we examine consumer cloud storage systems, focusing in particular on those systems that attempt to provide end-to-end security for customer data. We survey the security guarantees of current service providers and the issues they face, discuss open research questions, and highlight the challenges that impede the deployment of end-to-end secure cloud storage.

The article is published in the IEEE Security and Privacy magazine here.

The author-version of the article is available here.

This is a paper outside of my normal research area. We publish the first unified data set, consolidating data reported by the government (e.g., FISA and ASTR reports), companies (transparency reports), and published NSLs themselves. We analyze the collected data and draw conclusions about how the use of NSLs by government agencies developed over time.

Abstract

Government investigatory and surveillance powers are important tools for examining crime and protecting public safety. However, since these tools must be employed in secret, it can be challenging to identify abuses or changes in use that could be of significant public interest. In this paper, we evaluate this phenomenon in the context of National Security Letters (NSLs). NSLs are a form of legal process that empowers parts of the United States federal government to request certain pieces of information for national security purposes. After initial concerns about the lack of public oversight, Congress worked to increase transparency by mandating government agencies to publish aggregated statistics on the NSL usage and by allowing the private sector to report information on NSLs in transparency reports. The implicit goal is that these transparency mechanisms should deter large-scale abuse by making it visible. We evaluate how well these mechanisms work by carefully analyzing the full range of publicly available data related to NSL use. Our findings suggest that they may not lead to the desired public scrutiny as we find published information requires significant manual effort to collect and parse data due to the lack of structure and context. Moreover, we discovered mistakes (subsequently fixed after our reporting to the ODNI), which suggests a lack of active auditing. Taken together, our case study of NSLs provides insights and suggestions for the successful construction of transparency mechanisms that enable effective public auditing.

Full paper

Data Set

Our data set and processing scripts are available on GitHub.

Paper: “MEGA: Malleable Encryption Goes Awry”

MEGA is a leading cloud storage platform with more than 250 million users and 1000 Petabytes of stored data, which aims to achieve user-controlled end-to-end encryption. We show that MEGA’s system does not protect its users against a malicious server and present five distinct attacks, which together allow for a full compromise of the confidentiality of user files. Additionally, the integrity of user data is damaged to the extent that an attacker can insert malicious files of their choice which pass all authenticity checks of the client. We built proof-of-concept versions of all the attacks, showcasing their practicality and exploitability.

Website

On https://mega-awry.io, we provide an accessible overview of our attacks. The website includes videos of our proof-of-concept implementations of the attacks and links to related information as well as the attack source code.

The source code of a proof of concept implementation of the attacks are published here.

Paper

We provide an in-depth technical discussion in our paper that was published at IEEE S&P 2023 with the title MEGA: Malleable Encryption Goes Awry. This paper won the distinguished paper award at IEEE S&P.

Master’s thesis

This paper was the reslut of my master’s thesis at ETH Zurich. Originally, I looked at implementing and evaluating puncturable key wrapping for cloud storage systems at the Applied Cryptography Group. But then we got on a (fruitful) tangent and analyzed MEGA, the biggest cloud provider that offers end-to-end encryption at the time, and found serious flaws in their cryptographic design.

Cloud Storage Systems

Cloud storage security gained significant importance in the last decades due to the vast amount of outsourced sensitive information.

The following table shows different cloud storage services, their user base, and whether or not they have End-to-End Encryption (E2EE). The sources for the information in this table can be found in the thesis.

We notice that MEGA is the largest cloud provider which is designed to provide E2EE.

This thesis contributes four severe attacks allowing a malicious service provider or man-in-the-middle adversary who compromises the TLS connection to break the confidentiality and integrity of user keys and files in MEGA.

We exploit the lack of ciphertext integrity of the encrypted and outsourced RSA private key and characteristics of RSA-CRT to perform a binary search for one prime factor of the RSA-2048 modulus and recover the secret key—with lattice-based optimizations—in 512 user login attempts.

The second attack decrypts sign, chat, share, and file keys by exploiting key reuse and knowledge of the RSA private key. It is practical and only requires a single login attempt of the victim to decrypt a file key.

The third attack allows an adversary to frame users by inserting new files indistinguishable from genuinely uploaded ones. Finally, the fourth attack contributes a new variant of Bleichenbacher’s attack on PKCS#1 v1.5 adapted for MEGA’s custom padding scheme, which tolerates small unknown prefix values through a new guess-and-purge strategy.

We discuss the significant challenges, introduced by MEGA’s massive scale, to a fundamental redesign of MEGA’s architecture and suggest short-term and long-term countermeasures.

We generalize our findings, examine the reasons for flawed cryptography in large-scale applications, and advocate for a cloud storage standard to improve the security and transparency of cloud providers in practice.

The complete thesis is available in the Research Collection of ETH Zurich.

Acknowledgement

I would like to thank my supervisers Prof. Dr. Kenny Paterson and Matilda Backendal for their amazing support during this project. Our meetings were always an enthusiastic and insightful exchange of ideas.

Overall, this outstanding research experience reassured me in my decision to pursue a Ph.D. after finishing my Master’s degree.

Abstract

In recent years, Fully Homomorphic Encryption ( FHE) has undergone several breakthroughs and advancements leading to a leap in performance. Today, performance is no longer a major barrier to adoption. Instead, it is the complexity of developing an efficient FHE application that currently limits deploying FHE in practice and at scale. Several FHE compilers have emerged recently to ease FHE development. However, none of these answer how to automatically transform imperative programs to secure and efficient FHE implementations. This is a fundamental issue that needs to be addressed before we can realistically expect broader use of FHE. Automating these transformations is challenging because the restrictive set of operations in FHE and their non-intuitive performance characteristics require programs to be drastically transformed to achieve efficiency. Moreover, existing tools are monolithic and focus on individual optimizations. Therefore, they fail to fully address the needs of end-to-end FHE development. In this paper, we present HECO, a new end-to-end design for FHE compilers that takes high-level imperative programs and emits efficient and secure FHE implementations. In our design, we take a broader view of FHE development, extending the scope of optimizations beyond the cryptographic challenges existing tools focus on.

Full paper

Here is Alex Viand’s presentation of the paper:

My Contribution

I had the opportunity to contribute a Python frontend to HECO while working as a research assistant at the Privacy Preserving Systems (PPS) lab of ETH Zurich.

Other systems like Microsoft’s EVA trace computations and build a (potentially large) expression that represents the program’s computation. EVA then compiles this expression to SEAL code, which is a library for Fully Homomorphic Encryption (FHE). Unlike them, our frontend extracts the abstract syntax tree (AST) from the Python program and translates this to HECO’s internal AST. This internal AST still has standard programming paradigms such as loops. Later, HECO optimizes the internal AST and translates it to FHE code. Using an AST instead of a single expression to represent the user’s Python program enables high-level optimizations as it avoids obscuring the program structure.