Open Whisper Systems (OWS), the developers behind the open source and end-to-end encrypted Signal messenger, announced that they are experimenting with server-side “secure enclaves” to store and process contacts in a way in which the contacts aren’t revealed to them. This way, the organization hopes to make Signal conversations even more private than they’ve been in the past.
Issues With Existing Contact Discovery
According to OWS, someone's contact list his or her own social network. That's why not everyone may enjoy when an app asks for access to that list—they know those apps may upload their contacts to the cloud, where it may or may not be secure against other parties obtaining it through commercial deals, data breaches, or even government requests.
Signal aims to be as privacy-preserving as possible. This is why the developers behind it invented the Signal protocol, which enables one of the best known ways to communicate securely with someone over the internet. However, Signal, like many other encrypted chat applications or email services, can’t really protect the metadata, or the records of the communication, even though the content itself is secure.
In order for Signal to learn if someone’s friends (from the address book) are also Signal users and connect them with each other, the app needs to first look at the phone’s contact list. OWS doesn’t want to know the contents of anyone’s messages, but Signal needs this metadata to work.
Even so, the Signal developers have used the following method to try and preserve users’ privacy:
The client calculates the truncated SHA256 hash of each phone number in the device’s address book.The client transmits those truncated hashes to the service.The service does a lookup from a set of hashed registered users.The service returns the intersection of registered users.
However, according to the developers, such hashes, where the “keyspace” (the total hashes corresponding to someone's contact list) of all possible identifiers is too small, can always be inverted and the users identified.
This wasn’t an ideal solution, but together with OWS’ “zero knowledge” policy of deleting all records as soon as they are no longer needed, it meant that the users’ contacts were still relatively private.
Finding A Better Way
One of the problems with the previous method is that rogue Signal developers, malicious hackers, or a government agency could potentially modify the code of Signal’s servers so that the users’ phone numbers are revealed and collected.
OWS wants Signal users to trust that something like that can’t happen, so it has been experimenting with Intel’s Software Guard Extensions (SGX) to protect against those types of “attacks.”
SGX allows server operators to set-up “secure enclaves” that are isolated from the host operating system and kernel, similar to ARM’s TrustZone, which currently protects sensitive data such as a phone’s encryption key or biometric authentication data.
Much like with TrustZone, one of the primary roles of SGX is also DRM. A server could stream protected video to a client enclave with the assurance that the software playing back the content is authorized to do so.
OWS said that it has turned this model on its head. The organization will use the SGX enclave on the server-side, where the server could do operations on encrypted data, without learning what that data is.
Then the contact discovery process will work as follows:
Run a contact discovery service in a secure SGX enclave.Clients that wish to perform contact discovery negotiate a secure connection over the network all the way through the remote OS to the enclave.Clients perform remote attestation to ensure that the code which is running in the enclave is the same as the expected published open source code.Clients transmit the encrypted identifiers from their address book to the enclave.The enclave looks up a client’s contacts in the set of all registered users and encrypts the results back to the client.
This SGX-based method should significantly increase the privacy of Signal users, but it may also have its own flaws. Much like TrustZone and other similar secure enclaves, you still have to trust the chip’s manufacturer that there’s no hidden way to look at that data.
Uh oh. Search for Intel Management Engine if you do trust Intel in this respect. You can hide it from the OS but you cannot hide it from the CPU, or the CPU's parasitic twin.
BTW, for AMT running outside the CPU package, the SGX-protected memory is definitely encrypted. Even for SoCs which have it onboard, I think it's still encrypted. The SGX encryption/decryption should happen in the core performing the access. So, I think SGX should be safe from IME exploits.
Anyway, kudos to these guys for finding a good use for this DRM stuff.