Signal Increases Their Reliance on SGX
Over the past few years whenever Signal has faced a problem that has seemed insurmountable by using traditional or new cryptographic constructions, they have fallen back on using Intel’s SGX. SGX offers the Signal developers some extremely desirable functions.
However, critical analysis of SGX has frequently revealed it to be a fundamentally unreliable technology. Unlike the cryptographic constructions we have used over the past 30 years, SGX is more exploitable with new breaking issues found every few years.
This article will focus first on what SGX is, how Signal uses SGX, it’s proposed benefits, and then the issues with SGX and Signals implementation of SGX.
What Is SGX?
Intel Software Guard Extensions (SGX) is a set of CPU instruction codes which allow the CPU to create special enclaves (private regions of memory). Inside of these enclaves, the CPU can execute code without external processes being able to read or save the code being executed inside the enclave. SGX also supports a feature called remote attestation which allows a client to verify code running on a Server is the expected open-source code.
Uses in Signal
Due to the very attractive principles that SGX provides, Signal has implemented it within both existing and newly proposed features. These include:
- Contact discovery
When you sign up to Signal, you enter your Phone number and Signal will automatically connect you with other contacts who are also using Signal. Signal can do this because the app scans your phone's contacts list and discovers users who are already signed up to Signal using the same phone number. Users who are in your contacts list and in Signals user database are then added as a user who you can then instantly message on the app.
However, the naive implementation of the above scheme would lead to the Signal servers being aware of each person’s full contact list when they sign up to Signal. Instead, Signal performs this contact discovery process inside an enclave. This enclave allows for the Signal server to provide a remote attestation that the code running inside the enclave is the same code they have published online, and also ensures that the Signal servers cannot exfiltrate the user's contact list from the enclave. The final result produced by the enclave will simply be the intersection (the matching Signal users) of the contact list and all users signed up to Signal.
- Usernames and Social Graph storage
Signal has published a recent blog outlining with a preview for their upcoming username feature here. The basic premise would be to allow a user to specify a passphrase or pin, stretch that passphrase using a Key Derivation Function (KDF), and then combine that key with some secure random number generated by Signal servers. This becomes the master key allowing a user to recover a social graph or generate additional application keys. The important part is that access to this randomness can be limited since it is held on the Signal servers and the master key cannot be recovered without this randomness. This removes the ability for users to simply brute-force keys, since Signal can implement authentication requirements, like requiring a CAPTCHA for each guess.
However, this idea also revolves around SGX since the secure random value that is generated when the passphrase is selected must be unknowable by the Signal developers, or they could just brute force all Signal passphrases. SGX is also required because the user must send a hashed copy of their passphrase directly to Signal servers, the Signal servers cannot know what the user's passphrase is otherwise they would be able to recover their master key and social graph, even if they didn’t have the secure randomness. Thus, the randomness for each passphrase is generated inside the secure enclave and the comparison between the hashed passphrases also occurs inside the secure enclave. This means that the Signal server should see neither the hashed passphrase nor the secure randomness associated with it.
If all works well, this scheme should allow users to carry around a (traditionally) somewhat weak passphrase like “Melon1284” and have that passphrase be protected from brute-force attacks while still being able to fully restore their account.
- Value transfers (Mobilecoin)
Moxie Marlinspike, co-founder and creator of Signal, seems is also involved in Mobilecoin as an advisor. Although completely unconfirmed, there has been some speculation that Mobilecoin would be integrated into Signal as a currency.
Mobilecoin may have been the inspiration for the recent Signal secure value recovery. Mobilecoin published a paper in 2017 that says:
Running MobileCoin in an SGX enclave allows nodes to securely manage keys for users. A client can perform remote attestation to its MobileCoin node before transmitting its keys into the remote enclave along with a short recovery PIN. The MobileCoin node can then rate limit authenticated access to the keys, while the enclave prevents the node operator or anyone who compromises the node from circumventing the software and attempting to brute force access to the keys directly
This design is very close to the process Signal will use, however, Signal will substitute cryptocurrency keys with Signal public-private key pairs.
The problem
So now that we have a reasonable understanding of what SGX is and how Signal uses it, let’s take a look at some of the issues with SGX.
- Data and computations held inside enclaves can often be extracted through side-channel attacks
- SGX is fully proprietary, only supported on some intel processors and requires the use of property intel APIs
- Problem 1
This issue has been highlighted by a recent paper published here. This vulnerability allows for more general SGX attacks but as part of the paper, they explore Signal’s Contact discovery and Secure value recovery scheme. Regarding contact discovery, they state:
By completely breaching SGX in the manner described in Section IV, a malicious Signal server would be able to create an enclave that exposes all of the data it receives, while at the same time proving to clients via remote attestation that the enclave is performing the benign, published operations of private contact discovery. This would enable them to be able to read out the users’ hashed identifiers and perform a dictionary attack to learn the contents of the users’ address book, thereby nullifying the purpose of incorporating SGX into private contact discovery.
And regarding the secure value recovery scheme Signal uses they say
“By breaching the confidentiality of the enclave, an attacker can extract c2… referred to as the [Secure Random] in this article “…and gain an unlimited number of attempts to brute force users’ passwords.”
This is not the first time SGX has been compromised either. Various side-channel attacks have previously been found including:
Although not all of these attacks are directly applicable to Signals implementation of SGX, this shows a concerning trend of SGX being vulnerable to active and side-channel attacks.
- Problem 2
Intel offers an SGX remote attestation service themselves but requires the user to complete a corporate licensing agreement and be approved by intel on a case by case basis.
Intel also allows cloud providers to provide remote attestation services through their own cloud platforms, however, from publicly available information it seems that this service is only available on IBM, Alibaba, and Microsoft Azure cloud platforms
If Signal is truly accepting of the principles of open-source software why are they basing key features on SGX which has extremely limited deployment in datacenters? These features make it extremely difficult to deploy open-source forks of Signal which integrate with the network.
Conclusion
Knowing all we know now, it seems clear that Signal’s reliance on SGX is a potential security risk. SGX has proven to be insecure time after time in a number of ways by numerous researchers. As an individual user, you have the choice to remove yourself from any potential exploits by using a messaging application that does not rely on SGX.
Here are just a few messengers that don’t use SGX:
Please let me know if you enjoyed this type of content in the comments below and I can look at doing more content like this in the future.
